The pop-culture concept of a silver bullet – a simple solution to a hard problem – is a dangerous idea. It can be used to over-promise, and doom a team to under-delivery. When an executive, too far removed from what makes creating products hard thinks of “agile” as a silver […]
Business Analysis / Kano Analysis / Prioritization / Product Management / Requirements / Requirements Models
Posted on:
Don’t Prioritize Features!
Estimating the “value” of features is a waste of time. I was in a JAD session once where people argued about if the annoying beeping (audible on the conference line) was a smoke alarm or a fire alarm. Yes, you can get to an answer, but so what?! The important […]
Flashback
Posted on:
Flashback: This Week in the Past on Tyner Blain [May 3]
A look back at the best from this week in the past.
Flashback
Posted on:
Flashback: This Week in the Past on Tyner Blain [Mar 15]
A look back at the best from this week in the past.
Business Analysis / Product Management / Requirements / Requirements gathering / Requirements Models / Software requirements specification
Posted on:
SRS Plan of Attack
How do you approach starting a small requirements project as part of a large initiative within a massive enterprise? Do you boil the ocean? Your customer knows she needs “requirements” to give to her development team. She asks you – what will you deliver, and how long will it take? […]
Business Analysis / Project Management
Posted on:
Estimating an Inestimable Project
We create cost estimates at many times in a project. From budgetary estimates at the start of a project all the way to PERT estimates of tasks in a work breakdown structure. Creating a budgetary estimate seems impossible – you have to make many assumptions, your estimates are based on […]
Agile / Communication / Process Improvement / Project Management / Software development / Testing
Posted on:
Crossing The Desert With Bad Project Planning
Johanna Rothman recently wrote an article with a poignant introduction: “A project team focuses on an interim milestone, works like the devil to meet that milestone. They meet the milestone, look up, and realize they’re not at the end of the project–they still have to finish the darn thing. They’re living the Crossing the Desert syndrome.” Fixing it isn’t enough – how do we prevent it from happening?
Business Analysis / Requirements / Requirements gathering
Posted on:
Estimating the Effort of Documenting an As-Is Process
Estimating the gathering of requirements is hard. Not as hard as scheduling innovation, but easier than estimating implementation effort. One step in gathering requirements is often the documentation of the “as-is” process – how things exist today. We provide a framework for building those estimates – making the job a little bit easier.
Requirements / Software requirements specification
Posted on:
Joel Spolsky Speaks Specs
It seems that specs are like flossing: everybody knows they should be writing them, but nobody does.
Another for the wish I had said that list. Joel Sposky wrote a four part series on writing functional specifications in Oct 2000. Joel’s opening position is that all projects lasting more than a week, or with more than one developer, will be completed faster with specs than without them. He presents three giant reasons to use a requirements document as part of developing software
Three Giant Reasons