At the Agile Specification, BDD and Testing Exchange last month in London, Dan North spoke about selling behaviour driven development to the business. He put forward a relatively controversial idea on estimation: treat all stories as equal. Estimate each story as size 1 and just be done with it. Although this idea might seem overly simplistic, I find it really appealing.
Story estimation is one of those things where the process of doing it is more important than the output. Planning poker is a very effective technique to discover differences in understanding. However, BDD achieves the same by getting an agreement on scenarios. Specification workshops go much further than planning poker in building a shared understanding of the tasks at hand and definition of done. Teams that practice BDD or agile acceptance testing could skip planning poker if only there was some other effective way to get a sensible feel of how long a project phase will take. That’s why I find Dan’s idea so appealing.
On a decent-size project, the estimates will average out anyway. Treating all stories as medium size and figuring out how long a medium story will take will not be any less accurate than doing more detailed estimates and adding them up. It will, however, save quite a lot of time.
As a nice side effect, this should also produce a better breakdown of stories. Any story that obviously stands out by complexity will have to be broken down into smaller pieces, as we are not allowed to give it a higher valuation. Evenly-sized stories make it easier to establish a constant pace of delivery.
|
|
Hi Gojko,
That’s really an interesting concept. I’ve been introduced to it during Tom Looy’s talk about Lean+ToC:
http://vimeo.com/6440653
It also seems way easier to identify possible bottlenecks using this approach.
Cheers,
Ivan
I have serious reservations about this approach for estimating enterprise backlogs. Requirements specification is a Just In Time process. The idea that one should decompose everything would generate far more effort then it is worth. Most large backlogs are also used to provide roadmaps. At the team level with relatively well formed requirements this approach seems more feasible.
The reality of estimation is it is for making investment decisions and expectation setting. The estimation results are more for the business than the team.
It’s not news that long-lived projects (ones that run for several years) can plan and track iteration to iteration by counting stories rather than estimating in detail.
Robin’s point regarding investment choices is an interesting one because that’s a very vexed subject. DeMarco suggests that projects where one needs to make a very finely judged call on investment vs return are projects that one maybe shouldn’t bother with, and McConnel tells us that the purpose of estimation is not to predict the outcome of a project but to test if the expectations are realistic enough that one could expect to manage the project to success.
There is a decision point for projects which (in RUP terms) lies between “inception” and “elaboration” at which time everyone should have agreed that the project looks viable and should go ahead. Far, far too many projects, especially ones in the “enterprise” domain, sail through that decision point without any actual decision being explicitly made (and too many projects go on to deliver no value because of that). Someone, somewhere should be asking: to an order of magnitude how much is this likely to cost, to an order of magnitude what is it likely to be worth, and if the second value doesn’t greatly exceed the first they should cancel the project.
To make a decision at that point requires cost estimation. But we know that the very best estimation possible at that point has an uncertainty near to a factor of 4 either way (that is, a project with a 1 year estimate should be expected to actually take anything between 3 months an 4 years). And we know that the only way to get really goo estimates is through the learning that comes from building the system, and we know that the requirements will change as we go. To get that early order of magnitude estimate techniques like Planning Poker (and it’s elder sibling, Wideband Delphi) can be very effective.
What we shouldn’t do is induce an analysis phase where we try to go all the way down the backlog estimating every task on every story. Even iteration-to-iteration I encourage teams not to estimate tasks. And within a release plan, estimation of stories is probably a transitional practice.
The reason we would do it is to set an expectation (and not make a prediction) of what will be in the release. We do this to create a sense of confidence that the development team will deliver. Once that confidence is in place and a team is performing consistently the need to do that estimation fades away, as many of the lean advocates suggest.
On my current software project, we find this concept more than appealing – we find it works!
Every story starts out life as a 1-point story and should be able to be turned around in 8 hours from start of specification to customer acceptance.
If it turns out the story took more time, we run a quick post-mortem to find out why and then add a new rule to one of our “yardstick” documents (we have one for specification, one for development, one for testing). Now we have a better yardstick (get it?) for analyzing and possibly rejecting a story.
Yardstick documents can also have quality concerns in them as well in order to deal with “weak” stories that are certainly 1-point or less, but produce poor results. An example of this is a story with no behaviorial tests other than a “happy path” specified. This can certainly be turned around in time, but the results are likely to be bad.