Monday, September 28, 2009

The Five Essential Ingredients of Great Agile Estimation

Planning Poker is a useful Agile estimation technique (see previous post "Introduction to Planning Poker"), but it is even more useful when used in conjunction with whole teams, user stories, velocity, and story points. I refer to these five practices, used together, as the five essential ingredients of great Agile estimation.

Whole Teams
A key practice of Agile development is the use of whole teams. A whole team is a cross-functional team comprised of between 5-9 people. By cross-functional I mean the team as a whole contains all of the skills needed to accomplish the team’s goals, not that each team member is capable of doing any task. If you have more than 9 people, then you split people up into multiple whole teams.

Planning Poker reminds everybody that the estimate includes all of the work that needs to be accomplished in order for the story to be considered done. It includes development, testing, documentation, and anything else required for the story to be considered done. It is a reminder that nobody on the team gets credit for a job well done until the whole story crosses the finish line. Instead of people saying “well, I finished the development, I don’t know what is taking the tester so long” they are more likely to say “what problem are you running into and how can I help?”

User Stories
Because user stories are a simple and easy to understand description of the work, user stories allow you to focus on estimating rather than spending lots of time discussing what a particular enhancement request or requirement really is. To maximize the benefits of Planning Poker, you need to be good at creating and using user stories.

Story Points
In my experience, the best unit to use for estimates is story points. Two different people with two different skill sets or levels of ability in an area may take different amounts of time to perform a particular task. Estimating in hours mixes together the scope of the work that needs to be done with the speed at which a particular individual can do that work.

On the other hand, story points are a relative measure of the scope of a user story. Story points separates out the “what” from the “who.” For instance, if you have one individual that is stronger with .Net than with Java, they will estimate a Java story as taking more hours than somebody that is stronger with Java. But they will probably both agree that something that is twice as easy to implement will take half as long to do.

To use story points, you need to create a relative scale of scope. A simple approach is to find a simple and straightforward story that you use to represent a single story point. Then think of stories that are 2, 3, 5, and 8 times larger in scope. You should have a couple of examples for each story point value to take into account that some stories have more test than coding, more documentation than test, etc.

Story points are primarily used for planning, not for implementation. Story points are used to help determine the contents of an iteration by calculating a velocity.

Velocity
In Agile, the velocity of a team is simply the number of story points associated with stories that are finished in an iteration. For instance, if the team completed 8 stories that were each 5 points in an iteration, then their velocity for that iteration was 40 story points. In a stable team, a team that is comprised of the same individuals working full time as part of that team, the velocity is a good measure of the overall throughput of the team.

Knowing your velocity helps with planning. For example, if you know that the velocity of your team is 40 points, then you know you can expect 40 story points for each iteration. The team decides which stories to take based on the backlog which is maintained by the product owner.

More Than the Sum of The Parts
Regardless of which of these practices you are currently using – whole teams, user stories, story points, velocity – Planning Poker is an excellent tool. The more of these practices you use, the more they reinforce each other and the more value you will get out of Planning Poker. Conversely, the more you use Planning Poker, the more value you will see in implementing all of these practices.



Next: Planning Poker Reduces Risk and Waste

3 comments:

Saurabh Banerjee said...

I think the "Whole Team" perspective works well only for small projects/products or new development.

For bigger projects we need frequent involvement of Subject Matter Experts (for domain knowledge), Architects (for technical knowledge), usability experts for UI design, specific developers (for specific technical skills like SAML SSO, Web Services, etc).

Damon Poole said...

Saurabh,

Think of switching to whole teams as a transition that may take years. I've seen this work quite well with engineering teams composed of 80+ teams. It took time, but the subject matter experts became embedded where possible and because it was easier for people to learn and take risks, they did. And now there is more widespread expertise. I say "more" because some expertise is very difficult to transfer.

I also find that with incremental design, there is less need for big-A architecture and the architecture becomes simpler. I do believe that there is still a place for domain experts and architects, but the level of need and the application of that specialization is different and overlays quite nicely on whole teams.

In the past, many people became pigeonholed, not growing as much as they were capable of. Intellectual bullying can also be a factor in keeping folks from contributing at the highest level they are capable of.

To put it another way, I believe it is worth the effort of going as far as possible towards whole teams, learning how to make it work along the way. There is risk of taking it farther than a given team is ready for, but why not push the limits, find them, and see if over time they can't be pushed even further?

As you say in another comment, trust the wisdom of the individual teams (including the super-team composed of the individual teams) to find the way.

manav said...

Great thoughts you got there, believe I may possibly try just some of it throughout my daily life.






Function Point Estimation Training