All agile methods have one common premisse: prioritize your features by business value. But how can we calculate this thing called business value?
I did some research recently and found this incredible technique called “Impact Estimation”, by Tom and Kai Gilb. There is also a paper by Ryan Shriver that explains it really well. I’ve been applying it for some time now and it is working really well in my context. What do you think? Can this technique help you too? I hope so!
During the planning meeting, two sprints ago, after the team made their estimates, I proposed: what if we split the stories with estimates bigger than 5? Their first reaction, as expected, was: are you crazy? These are the smallest stories we can think! Ok, I said, so let’s analyse one by one…
An important statement is that the “5” here is about our team’s scale. Other teams can have different scales.
Analysis results
After the analysis, some stories that were 13 became two stories, and the sum of their estimates were in general less than 13. Also, some stories that were 8 became two stories, with their estimates’s sum also less than 8. Just in some very very special cases we kept an 8. But we struggled to split all stories above 8.
Sprint results
All stories were DONE by the end of the sprint. The main advantages of splitting big stories is that the team often cuts out most of the uncertainties by doing it, and the result often is more stories with less points, which can be translated to more velocity.
After applying the James Grenning’s companion planning poker games to estimate our releases, I became concerned about how to maintain the story points scale in the next estimation meeting, since we’ve dropped the traditional “an easy story as base”, and jumped to “an easy column of stories as base”.
The fact is, the solution is simple. I’ve just brought all the stories of the last sprint to serve as a base, and the team used it as column examples. The difference between this estimation meeting and the first one is that in the first one the team had no base, and just organized the stories in columns of similar difficult. Using the last sprint as a base, the team just slided the new stories under the already estimated stories, using the old ones as parameters. This even eliminated the need of planning poker for a good amount of columns, since we had enough stories as examples.
Also, I was in doubt if I should bring all the stories of all last sprints to use as a base, or just the stories of the last sprint. The thing is, the larger the range of points we bring as examples, the better the team will be able o maintain the story points scale. And also, fresh stories are better parameters than very old ones.
My conclusion is that we can apply the techniques proposed by Grenning every time, obtaining very good estimates every time! Just keep bringing the stories of the last sprint to help maintain the story points scale.
In a recently endeavour to find the blogs of all Agile Manifesto’s authors, I’ve found this post of James Grenning about some planning poker companion games. Luckily, we were about to do a release planning for both Brasigo and BlogBlogs here at WebCo, just the perfect opportunities to try a new approach to estimating.
The results:
Why?
Conclusion
I highly recommend this method! Not only for release plannings, but for all estimation sessions. It is deep enough to do always.
Tiago Motta Jorge's Professional Blog 