“So…how long do you think this will take?” And just like that, you find yourself facing the critical question of how to do agile estimation.
It’s the most-feared question of anyone who’s in charge of a software development project.
I’ve been kept up nights by this question. Broken out in a cold sweat. Lost my appetite.
I’ve spent hours breaking features down into tasks. I’ve locked a team in a room for days to create time estimates.
I once spent an entire month creating an estimate for an eight-month project.
“Why the hell does estimating software have to be so hard?!”
It’s not hard.
I just didn’t know the right process back then.
Elements of Agile Estimation
Agile estimation delivers very good results using a method that’s repeatable, simple, and fast. There are a few key elements:
- User stories are a way to describe the desired functionality of the software in a lightweight fashion.
- Story points are used to assign an abstract estimation of relative size to each user story.
- Planning poker is used to leverage the team’s experience to estimate the size of user stories, in a way that encourages debate and discussion to uncover potential “gotchas.”
- Velocity is a measure of how fast the team can complete user stories in an iteration, based on an estimate and/or historical performance of the team.
- Duration is calculated by dividing total story points by velocity and multiplying by iteration length.
Using these components, you and your team can very quickly establish a projected timeframe for any scope of work.
Step 1: Write User Stories
Read our companion blog post on this subject: Writing User Stories: It’s not as Difficult as You Think
A user story is a description of a feature that is very lightweight, easy to understand, and quick to write. One of the key benefits is the ability to describe the vision of the project to the team without spending weeks creating detailed requirements.
Elements of a User Story
There are two parts of a user story:
- The Title, which summarizes a desired feature.
- Acceptance Criteria, which provide a checklist of what’s needed in order to call the story “done.”
Writing the Title
Start with writing the title of the story. Here are some examples:
- As an author I want a spell checker so I can avoid spelling errors in my documents
- As a shopper I want a wishlist so I can remind myself of things I’d like to buy in the future
- As a salesperson I want a sales forecast report so I can ensure I’m on track to hit my quota
Notice that the title follows a very specific format:
As a [role], I want [capability], so I [benefit]
This provides huge value to anyone who reads the story. From the title alone you can get context about the feature and you can put yourself in the user’s shoes.
Writing Acceptance Criteria
In order to estimate the size of a story, the team will need to understand some details about the vision of what’s desired. There’s a big difference between the team thinking they’re checking spelling in English only and you were thinking English, French and Spanish, for example.
Think of acceptance criteria as a checklist you’d use after the team delivers a new feature, to make sure they produced what you originally envisioned.
Here’s an example for the spell checker story:
- I can check spelling for my entire document
- I can step through each spelling error one at a time
- I can see suggestions
- I can replace my word with a corrected word
- I can add words to my dictionary
- I can check spelling in English
This level of detail provides a lot of insight for the team.
Step 2: Assign Story Points Using Planning Poker
Once you’ve created your list of user stories and written the conditions of acceptance, you’re ready to get the team together to estimate the size of each user story. “Story points” are an abstract measure of size that’s used to record how big each story is, based on the team’s opinion.
The Cohn Scale
Agile expert Mike Cohn has created a series of story point values that have built-in error correction of 50%. The scale is a range of values including: 0.5, 1, 2, 3, 5, 8, 13, 20, 40 and 100.
If you estimate a story as a 5, and you’re wrong by 50%, your estimate is really in the range of 2.5 to 7.5. For this reason there is no 4, 6, or 7 included.
By using this set of numbers when estimating, your total estimate for a list of stories will turn out to be remarkably accurate, because the errors cancel each other out rather than add up.
Planning Poker
Planning poker is a technique that allows the team to rapidly evaluate and size user stories. Here’s how it works:
- A user story title is read aloud or, ideally, put up on a projection screen or TV.
- The conditions of acceptance are discussed, questions asked, and clarifications are made.
- Each team member decides on a story point value and selects a card from a deck in front of them — these are special planning poker cards, each with a Cohn Scale number.
- Once each team member has selected a card, everyone turns over their cards.
- Any differences are discussed, typically with those with the highest and lowest estimates explaining their thinking.
- The team re-votes based on that discussion until a consensus is reached.
To purchase planning poker cards, see Mike Cohn’s Mountain Goat Software web site.
Step 3: Estimate the Team’s Velocity
Velocity is expressed as the number of story points the team can complete per iteration (“Sprint” in Scrum terms).
Assuming a sprint length of two weeks, velocity is the number of story points the team can complete over the course of this two week period.
There are a few different ways to estimate velocity:
- Run a sprint or two. This is the ideal situation. In this case the team simply starts building the first few stories, beginning with those which are the most important. Add up the story points for those that were driven to “done”–fully coded, tested, and deemed ready to include in the product–and use that as your velocity.
- Figure out how many story points will fit in a sprint. In this case the team sits down together and does a detailed breakdown of one or more stories, creating specific tasks with hour estimates. The team determines how many hours it has for project work in the next two weeks, figures out how many stories will fit (perhaps a combination of smaller and larger stories) and uses the total story points from those stories as the estimated velocity.
- Use the team’s average velocity from a similar project. This can work, assuming you have the same team, working with the same technology on the same product line. This is the least-favorite option.
Each of these agile estimation techniques will result in a different level of accuracy with respect to the team’s actual velocity over the course of the project. The next section discusses how to account for this.
Step 4: Calculate a Projected Completion Timeframe
You now have the two pieces of information necessary to create a time estimate, the total story points from your list of user stories, and a velocity for your team.
The Cone of Uncertainty
You could just use your velocity as-is, assuming that you are absolutely correct in your estimation of how fast your team will move. That’s a highly risky strategy, since as the project is executed, the team may find that things go more slowly than originally thought, or more quickly.
With agile estimation, the best approach here is to use a range of velocities.
We use multipliers from the “cone of uncertainty,” which is a concept borrowed from traditional waterfall development and adopted to agile. Multipliers allow a wider range of time estimates if you haven’t run any sprints for the project, with the range narrowing as you get more experience with how quickly the team can move.
Some examples of applying agile estimation:
- You’ve estimated the team’s velocity by breaking down stories into tasks and seeing how many story points fit into a sprint, and you’ve come up with 14 points. You’ll use the 0.6 and 1.6 multipliers since you have not run any sprints, for a range of 8.4 to 22.4.
- You’ve decided to start the project and run two sprints to get an idea of what the team can do. In the first sprint they completed 5 story points, and in the second sprint they completed 15, for an average of 10. You’ll use the 0.8 and 1.25 multipliers for a range of 8 to 12.5.
Calculating a Projected Duration
Now that you have your velocity range, you can calculate a range of sprints:
Low Sprints = Total Story Points / High Velocity
High Sprints = Total Story Points / Low Velocity
Using the first example above, and assuming 100 total story points, this looks like:
Low Sprints = 100 / 22.4 = 4.5
High Sprints = 100 / 8.4 = 11.9
To be safe, round up to the nearest sprint. This leaves us with an estimate of 5 to 12 sprints. Assuming two week sprints, this is a total of 10 to 22 weeks of production time.
As I mentioned above, once the team starts working, the range will get narrower, since you will then have actual evidence of how quickly the team can deliver this particular project.
In addition to production time, you may want to include time for other project activities. When we create our estimates, we typically also add time for:
- Ramping up the team, including transitioning them from other projects – 2 weeks
- Project launch, including setting up the development servers, source code repository, etc. – 2 weeks
- Release sprint – 2 weeks for every release we’re going to ship. If it’s a short project, there will only be one release sprint at the end. For longer projects we plan on release sprints every six to eight weeks.
Agile Estimation: Not Just Faster. Better.
By combining user stories, story points, and velocity, you can create initial estimates as well as continually monitor the projected timeframe as the project moves along. This technique is very fast and straightforward, which means it’s easy for the team to adopt and more likely to be utilized.
As new requirements come up during the project you can use this technique to provide estimates to stakeholders, which is extremely helpful when they need to make decisions about how to prioritize work on the project.
Editor’s Note: This post was originally published in August, 2015 and has been updated for accuracy and comprehensiveness.
