I’ve decided to do a bit of a brain dump about estimating stories. The idea (in an Agile way) is for this to be more of a discussion than a presentation of facts. I’m interested in the different ways people have explained to me how they estimate stories. Since these are not direct quotes I may have misrepresented them or simply, "got the wrong end of the stick". So please feel free to correct me or tell of me other ways you know of. Also note that currently this is unfinished but I’d like feedback ASAP, so I’ve published it.
Methods:
1. Iterative break down of a story
Assign est. to the story. If the est. means you cannot implement the story in a reasonable time (e.g. a sprint) then break the story into smaller stories and assign (hopefully) a smaller est. until all stories fit into the implementation window
1 a) Single story point
To create an est. the team come to a joint decision about the est., possibly using some form of est. poker, the customer can then (directly) compare stories via the "cost" if they wish
1 b) Multiple est. per story
To create an est. specialists in the team assign their own point score to the story. The customer (with the team) has an opportunity to compare stories including the specialist areas. E.g. A graphic designer may quote 5 and a front end developer 2 so the customer may say to continue with the front end work and leave the design for the next iteration/delivery. Another favourite seems to be to split the development and the testing time (probably for those not using a form of TDD)
2. All stories cost 1
Stories are broken down until the team agrees they’d score it 1. This means the stories are less prone to risk as they must be sufficiently decomposed for the team to be happy with a est. of 1. The customer can then make simple comparisons based on priority
3. No story points
Rather then use any specific form of estimation, stories are judged only on their priority. The stories are evaluated by the team but only at a high level to ensure they seem achievable in the chosen window, typically 3-4 weeks. Stories are then worked on in priority order and are done when they’re done. Kanban seems to use this approach.
Evaluation:
1 a) Single story point
The advantage of a single estimate is that the customer can compare the notional cost of stories. They’ve no idea what a cost is or consists of just that one is relatively more than another and you only fit so many story points into a sprint.
The disadvantages are the opposite of the advantages of 1 b)…
1 b) Multiple est. per story
You have have a team of people with different skills, so to come up with a total cost they can only sensibly estimate about what they do and not what it takes to do someone else’s job. One you have these separate estimates why not be transparent and show them to the customer? This way the customer can make fine grain decisions about the parts of story they want implemented (or changed to cost more or less).
The disadvantages are that the customer probably doesn’t want to get involved in the such details and they is opportunity to do so then it should probably be broken down into separate stories, e.g. one for the function behaviour, one for the design. You can argue that separate skill sets are required everywhere so if you took this approach where would it end, a database est., a UI est., testing est. etc. As a side note testing (and by that I mean both non and automated testing) should be part of the development cost
2) All stories cost 1
When you estimate a story that is more complicated than 1 then you may end up either taking more time to break the story down into smaller parts or tasks or you implement the story hoping you can figure it out as you go. So why not carry on breaking stories down until they reach a point that you can easily implement them or at least quickly know they’re wrong. Also the customer can now decisions based purely on priority rather than cost (is this practically correct?) A potential problem with this approach is that you may spend a fair amount of time travelling down a set of features that aren’t that important or worst may be thrown out after other iterations are completed and the customer no longer has a need for them.
3. No story points
Kanban is the mechanism I’m least familiar with, well actually I have no working experience with so you’ll have to forgive me for punting my ideas here. It would seem that you can save time by not worrying too much about estimating and rather concentrate on priority. I need to look into this much more.
(note to self; http://epistemologic.com/category/process/lean-software/)
As I’ve already mentioned this is unfinished and I’d like constructive feedback – so please resist the urge to simply flame me. Thanks.
IT Bytes 