One of the key advantages of adopting an agile workflow is the ability of the team to estimate new work effectively.
Over time, as team members encounter new user stories, they should develop an increasingly accurate sense of how they’re going to approach stories and how much effort each user story will take to complete.
Once a team has been working together for a while, their ability to estimate new stories becomes much better. Teams with a history of past successes and failures can compare their velocity against point estimates that everyone can agree to, and as a result they can predict with reasonable accuracy how difficult it will be for them to complete a new story.
But teams new to agile sometimes have difficulty figuring out how to estimate stories effectively.
For some, the abstract and team-specific concept of points is difficult to grasp. For others, the soft relationship between point value and actual time spent working on a story can be distracting.
Until a team has been working together for a while, attempts to generate accurate point estimates for new stories may feel awkward and loose.
Here are a few estimation techniques for agile teams that can ease the transition through this phase.
These techniques get everyone engaged in productive point estimation from the start, regardless of their level of experience with agile methods.
Planning Poker
Getting everybody in the team involved in the estimating process is critical to coming up with accurate estimates that reflect the true understanding and investment of the team.
Unless all team members participate actively, the ability of the team as a whole to estimate new stories will develop much more slowly.
Planning poker is a game that team members can play during planning meetings to make sure that everybody participates and that every voice is heard.
To begin, each team member is given a set of cards with numbers on them. The numbers are usually ordered from 0 to 21 using the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, and 21.
Then each story is read aloud. After each story is presented, everybody on the team is asked to hold up the card showing the level of effort that they believe this story represents for the team.
Initially the estimates may be all over the map. But after a while the team will get a sense of how much effort they all estimate is associated with a typical type of story.
Once all the votes are in, the team members with the lowest and highest estimates explain why they chose their scores.
Frequently, experts with detailed knowledge may be able to tell the rest of the team why a certain story is actually much easier than they thought, or why it may be more difficult than it first appears because of unexpected requirements.
Through this process, everybody on the team learns more about what’s involved in estimating stories both inside and outside of their specialties, increasing knowledge sharing across the entire team.
With planning poker, the numbers are significant. A story estimated as a 2 should be about one fourth as difficult as a story estimated as an 8.
Stories estimated at 20 or higher may be so large that they need to broken up into smaller stories before they can be attempted.
Stories estimated at 0 may not even be worth tracking.
T-Shirt Sizes
Using numbers is the most common approach for estimating points, but sometimes teams find themselves over analyzing when trying to arrive at a number of points.
If you notice that team members are getting caught up in the idea that the number of points associated with a story has anything to do with the number of hours involved in delivering the value of that story, it may be more effective to switch to a non-numerical system like T-shirt sizing.
With T-shirt sizing, the team is asked to estimate whether they think a story is extra-small, small, medium, large, extra-large, or double extra-large. By removing the implied precision of a numerical score, the team is free to think in a more abstract way about the effort involved in a story.
Some teams even adopt creative approaches such as using dog breeds to estimate stories. For example, “That story’s clearly a Chihuahua, but the other one is a Great Dane.”
Engaging the fun, creative side of the team while they’re estimating technical stories can be effective at getting them out of their analytical thought processes and into a more flexible, relative mindset.
There are some practical issues to consider when adopting T-shirt sizing for story estimation.
For one, non-numerical scales are generally less granular. While that can speed up the voting process by reducing the number of options, it may also reduce the accuracy of velocity estimates.
In addition, the ability to compare stories with each other can be a little bit more complicated, since there is no clear mathematical relationship between a medium and an extra-small.
T-shirt size scales also require extra effort on the part of the person coordinating the agile process. The T-shirt sizes need to be converted to numerical values for the sake of tracking effort over time and charting an estimated velocity for the team.
For that reason, while T-shirt sizes and can be very effective for teams just starting out with agile, eventually it’s a good idea to move the team toward a more rational numerical scale.
Relative Mass Valuation
When adopting agile as a new technique for a team, frequently there will be a large backlog of stories that need to be estimated all at once.
One of the biggest advantages of agile estimation is that stories are estimated relative to each other, not on the basis of hourly or daily effort. It’s usually clear to a team, regardless of their level of experience, if one story is going to be more difficult than another, even when nobody has any idea how long it may take to complete individual stories.
But going through the process of individual point estimation for a huge list of stories can be daunting.
Relative mass valuation is a quick way to go through a large backlog of stories and estimate them all as they relate to each other.
To use this approach, first write up a card for each story.
Then set up a large table so the stories can be moved around easily relative to each other.
Pick any story to start, then get the team to estimate whether they think that it is relatively large, medium, or small.
If it’s a large story, place it at one end of the table. If it’s a small story, it goes at the other end of the table. A medium story goes in the middle. Now select the next story and ask the team to estimate if it’s more or less effort than the story that you just put down. Position the story card on the table relative to the previous card, and go to the next card.
Using this technique, it’s possible to go through 100 or more backlog stories and estimate their relative effort in as little as an hour.
Everyone on the team will feel a sense of accomplishment when they see the scope of their work laid out in front of them, estimated in order of effort.
The next step is to assign points values based on the position of the stories on the table. Start with the easiest story that is worth assigning points to, and call it a 1.
Then move up the list of cards, assigning a value of 1 to every story until you get to one that seems at least twice as difficult as the first one. That story gets a 2.
You may need to remind the team not to get caught up in the fine details. The idea is to get a rough point estimate, not a precise order.
Ultimately, any story may be completed in any order based on the business value and priority assigned by the product owner, so all the team needs to estimate is how many points one story will take relative to another.
Conclusion
Using these simple techniques, it’s surprising how quickly a team with no pre-existing concept of point values can come to a very clear understanding of the relative value of all the different stories they’re faced with, even before they’ve established an effective team velocity.
The sooner your team starts estimating points and tracking their effort, the more effective point valuations will become.
Eventually, every team can become more adept at estimating new stories and develop its own scale for points that will factor into its own individual velocity.
M. David GreenI've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.
