Archive for the ‘estimating and planning’ Category

Measurable Value with Agile: the Impact Estimation technique

June 15, 2011

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!

Advertisements

How did splitting stories above 5 helped us

April 24, 2009

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.

Maintaining the story points scale

March 20, 2009

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.

Estimating stories faster and more accurately

March 9, 2009

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:

  • 20 stories estimated in just one hour!
  • much more coherent estimation!
  • much more accurate estimation!

Why?

  • faster due to the great amount of example stories per column of similar difficult, facilitating the comprehension of everybody;
  • coherent, because the team compared almost all stories against each other to correctly sort them in columns of similar difficult;
  • accurate, also due to the great amount of example stories per column of similar difficult, so that each column had much more information than a single story could give in an usual planning poker game;

Conclusion

I highly recommend this method! Not only for release plannings, but for all estimation sessions. It is deep enough to do always.