I just finished reading an excellent Blog entry on transitioning from traditional estimating to Story Point estimating by Ilan Goldstein. You can find the blog post at the following link:
transitioning-from-timebased-to-relative-estimation
The article walks through the estimation process used during the transition there are three excellent points.
1. I loved the idea about being above-board and listing the conversion table between Story Points and the range of hours typically associated with those Story Points. Let’s face it, everyone is doing the mental math and the only thing worse than people doing the calculation, is everyone using a different version of the table in their own head to do the calculation. So let’s all just agree what that conversion table is. Excellent.
2. Taking previous features developed and incorporating the effort they took into the estimation process is wonderful. I have not heard mention often enough about tracking and comparing estimates versus actuals on User Stories so that our estimating get better each Iteration. This process of creating reference User Stories in points by converting the hours they actually took helps to leverage the previous project work to make the estimating of future work as accurate as possible. Brilliant. The additional step to then throw away the hours per feature and use on the Story Points going forward is ideal.
3. The point to then track both the time completed and the time remaining on active User Stories ensures that we are continuing to learn and get better with our estimating as the project proceeds.
I think these three points just add the value of planning poker and makes the entire estimation process the best it can possibly be.
Why do I like these ideas and processes so much and what does that have to do with the title of this Blog?
It has always been a personal belief of mine that setting completion expectations for a project team with only a collective measure (velocity) for the entire iteration is not optimal. Using relative estimating to produce accurate estimates and using velocity to plan for the average progress of a project is fine, but even Mike Cohn stated he does not recommend using Story Points for Sprint Planning.
why-i-dont-use-story-points-for-sprint-planning
Mike Cohn mentions that velocity is not a useful short-term predictor and I agree. I would also add that not only is it not a useful short-term predictor, but also can possibly not set the proper short-term expectations for User Story completion times. When used, Story Points by their nature allow for a separation from day-to-day complexities that can cause inaccurate estimates. When used, Story Points by their nature can also allow for a separation from day-to-day expectations. For example:
- How long should a 1,3,5, or 8 point story take?
- Do we need to wait until the end of an iteration to react to a story that is taking longer than thought?
- Would knowing that a story should take 2 days on average help to alert the developer of potential issues?
- Would knowing that a story is going to take longer than expected allow for the splitting of a story in the middle of an iteration and the ability to deliver more ‘Done’ work in the iteration?
If I am for the most part only reviewing velocity at the end of the iteration and not at some level on each User Story during the iteration, am I limiting my opportunities for acceleration? (Acceleration being the rate I can change my velocity.)
Thoughts?
Agile PMO 