Estimating work (stories) probably is the hardest part in software development. Every team I have seen seemed to struggle with it. Lately, there is lot of talk about #NoEstimates. I heard this a lot when I was at global scrum gathering, Phoenix. I was kind of frustrated that the promoters of #NoEstimates didn’t offer any solutions.
The team I work with is a matured agile team that consistently delivered to production every two weeks over last 10 years. Yet, the team struggles with the estimation. Our Scrum Master conducted several experiments with estimation techniques. However, we couldn’t find benefit that we could quantify. We have been using modified fibonacci series.
I recently suggested an idea that we tried for couple of estimation sessions and seems to work better. Here it is:
We estimated using three-point scale
Small – If the story could be done in a week
Big – If the story can’t be done in a week but could be finished in the sprint (We run 2 week sprints)
Beyond – Can’t be done in a sprint and needs further refinement
Then product owner picks a number for Small and Big story (We decided to go with 2 and 4) and establishes the velocity. Our PO and Scrum Master did some digging into past history and found that the new way of estimation leads to the velocity that is pretty close to the current velocity.
Team generally felt that it is much easier to estimate this way since they don’t need to figure out if it is 0.5 or 1 or 2. If they know it is small, that’s good enough.
We only tried for 2 sessions and still don’t have lot of data to support that this is a better technique. I would like to go ahead and post this so that other teams could try (if interested) and post the results. Also, this technique may not be suitable for while estimating bigger projects with lot of unknowns.