Skip to end of metadata
Go to start of metadata

Effort to complete tasks in a project can be estimated several different ways. This wiki page is not meant to serve as comprehensive documentation on all estimation methods; rather it summarizes a few commonly used methods.

Hours

Estimating the hours it takes to complete a task or a project is very tricky and is often based on assumptions that may or may not be accurate. The following recommendations may help when estimating hours.

  1. Use a tool such a JIRA or FogBugz
  2. First, find out how accurate your estimate needs to be. The more accurate the estimate has to be, the more detail is needed–and that will take more of your time. Estimating a Rough Order of Magnitude (ROM) (-25 percent - +75 percent) can be done fairly quickly, at a high-level, and not much detail. But if you have to provide an accurate estimate within 10 percent, you will be spending quite a bit of time figuring out the details of what must be done. 
  3. Create the initial estimate of effort hours for each activity, and then for the entire project. There are lots of techniques you can use to do this, such as creating a Work Breakdown Structure (WBS), developing a PERT chart, or using Analogous Estimating (comparing a task to a similar task for which the amount of execution time is already known).
  4. Include the efforts of part-time workers and hired specialists–freelancers, trainers, technical writers, and so on.
  5. Don't forget rework. In a perfect world, project deliverables are exactly what the customer wants the first time. This is almost never the case in the real world. If you don't take into rework into account, you can end up grossly underestimating effort.
  6. Include the time you or others spend managing the project. Common practice is to earmark 15 percent of the project's total effort hours for project management. For example, if a project estimate is 12,000 hours of 7 - 8 people's effort, then a full-time project manager (1,800 hours) is needed. If the project estimate is 1,000 hours, the project management time is 150 hours.
  7. Add contingency hours. These reflect the uncertainty or risk associated with the estimate. If you're asked to estimate work that is not well defined, it's acceptable to add 50-75 percent or more to reflect the uncertainty. On the other hand, if you have done this type project many times before, contingency might be 5 percent.
  8. Calculate the total effort by adding up all the detailed work components.
  9. Review and adjust as necessary. Sometimes when you add up all the components, the estimate seems obviously high or low. If your estimate doesn't look right, go back and make adjustments to your assumptions. 
  10. Make sure the estimate seems reasonable to you and that you are prepared to defend it. If your sponsor thinks the estimate is too high, and you don't feel comfortable to defend it, you have more work to do on the estimate. 
  11. You will never know all the details of a project for certain. Therefore, document all assumptions. 

Why Hours Are Tricky and Frequently Deceptive

There are some real problems with using hours as your estimation unit:

  • No task takes 3 hours for every person. One person may be able to complete the task in half an hour. Another may take all day. In fact, the same individual will take different times to complete a task, depending on what's happening with that person on a given day. Ever notice how long it takes you to do something when you're not feeling well, or are distracted?
  • Hours immediately lock people into expectations. Tell a stakeholder that it will take 3 days to complete something, and you'll get asked at the end of those 3 days, "Well? Is it done?"
  • Estimating using hours, or "person hours," or days, or whatever time length can lead to sandbagging–padding the estimate to build in some slack. This practice is irresponsible and, needless to say, inaccurate.

These are just a few of the problems that come up when estimating using hours!

More Information on Estimating Hours

Story Points

“The venture capitalists I work with say they have never seen a correct GANTT chart in a board meeting. When they dig down into the problem they say none of their management teams knew the velocity of their teams before they implemented Scrum. Not knowing the velocity of production of the teams is the root cause of 100% failure of release plans to be accurate in their board meetings.” --Jeff Sutherland

Story Points are a powerful estimating tool that focuses on effort and complexity rather than hours. This approach drastically reduces planning time and results in more accurate estimates and release-date predictions.  Research by the Standish Group, the Forrester Group , the Rand Corporation,  Microsoft , and others shows that story points estimation is dramatically more accurate than estimating using hours, ideal hours, "man hours," and other traditional methods of effort estimation.

One of the reasons for this is that Story Points are more stable and predictable: A 3-point story is always a 3-point story. Hours, on the other hand, depend on who is working on the story and what that person is experiencing at the time.  The best developer on a project can take 1 hour to complete a task while the worst developer can take 10 or more hours. Or, the best developer might take 10 hours if he or she is multitasking, or simply having a bad week.

Estimating Story Points

Getting Started

A mature agile team intuitively knows what a story point means and can estimate the size of a user story by comparing it to other stories that it has sized in the past. New teams need some practice over a few iterations before they reach this comfort level.

First, make sure these things are established:

  1. Definition of Done. What does it look like when this task is completely done? This should include quality assurance, testing, 
  2. Sprint Length. Some XP teams sprint for a month, but generally, sprints (or iterations) should be no longer than 2 weeks.
  3. Understanding that high throughput is achieved via low work in process. Having a small number of user stories in flight (being worked on and not at ‘done’) in a sprint contributes to getting more things done. Having lots of user stories in flight is the same as multitasking. Multitasking is a productivity killer!
  4. Understanding that Story Points are about Complexity and/or Effort. Not hours. A complex story will require a lot of skill and attention. But a Story also can require a lot of effort without being complex.

Next, use one of these approaches:

I. Identify the smallest story, and work up from there.

Have the team take a look at a collection of stories of different sizes.

What is the smallest story? Give this 1 Story Point.

Are there other stories that are about the same size? Give them 1 Point also.

What is the next largest story? Will it require twice the effort? Give it 2 Points. Will it require three times the effort? Give it 3 Points. And so on.

Do this with each story in the collection until the team has estimated all the stories.

II. Triangulate.

Have the team take a look at a collection of stories of different sizes.

What is the smallest story? Give this 1 Story Point.

What's the largest story? How much larger is it than the smallest? Five times? Give it 5 Points. Eight times? Give it 8 points. And so on.

What story falls near the middle? Assign this Story the Fibonacci number that falls in or near the middle point between 1 and your largest story's points. For example, if your largest story is 20 points, give the middle story a 5.

These first estimates won't be as accurate as the ones your team comes up with as they get used to working with Story Points. That's okay. Don't stress over inaccuracies in early sprints. 

The other thing to keep in mind is that Story Points will have different values for different teams. It doesn't matter.

What matters is reaching consistency within the team and tracking your capacity (how much time your team can devote to the iteration) and velocity (how many story points the team can address during an iteration) over time. As you do this, you will find that your team will be able to complete a consistent number of points during each iteration. And if this deviates, it is a sign that something has changed that is affecting the team's velocity. This could be the gain or loss of a team member, a change in capacity, or some other phenomenon.

Some Examples of Story Point Calculations

These sample calculations can be useful for introducing your team, early on, to the concept of Story Points–say in your first discussion about them. Afterward, you should allow your team to evolve into using their own estimates by identifying the smallest story and working from there,  or by triangulating. 

PointsActivity
?
  • Likely small, but needs analysis
0
  • Tiny, but important (e.g. draft a thank you note to the CIO)
1/2
  • Fix some minor errors in a template
1
  • Participate in Project Work Session
  • Read a Gartner article
2
  • Write some instruction on something I know really well
3
  • Write some instructions that need a bit of research
5
  • Plan and give a one-hour presentation from scratch
8
  • Plan for and give a 4-hour workshop from scratch
13
  • Develop an intake process for a new service-related projects
20
  • Develop new reporting for leadership
40
  • Create and coordinate training on PM over next 100 days
100
  • Study for, and pass, the PMP exam
  • Refactor a year's worth of technical dept.
  • Set up a PMO

Planning Poker

Planning Poker is insanely useful for estimating the effort and complexity of tasks. It is based on the Wide-Band Delphi technique, which uses a modified Fibonacci sequence to guide teams to a consensus for estimating effort. You can use planning poker with any unit of estimation–hours, ideal hours, story points, "t-shirt sizes," whatever!

Planning Poker decks have cards showing some version of the the Fibonacci sequence, often this one:

0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? (unsure), and a coffee cup (meaning let's take a break)

The Fibonacci sequence reflect the inherent uncertainty in estimating larger items–the larger a story is, the greater the gap between the number of points. This also encourages teams to break epics up into smaller, more estimable, more manageable stories.

Planning Poker happens in the Iteration Planning stage, when the team is estimating the amount of work they can accomplish during the next Iteration, or Sprint. Here's how it works:

  1. Each member of the team gets a set of cards, each card a number in the modified Fibonacci sequence.
  2. The facilitator (often the ScrumMaster) presents the first User Story to the team, usually starting with the top-priority Story in the Product Backlog. The team discusses what the story entails until all members are satisfied that they understand the work involved.  
  3. On a signal from the facilitator, each member holds up a card showing how many story points he or she think are involved. 
  4. If there is a clear majority of one number, that is the number of points that get assigned to that story.
  5. If there is a split, then the following happens:
         The person holding up the highest number explains his or her rationale.
         The person holding up the lowest number explains his or her rationale.
         The team discusses, as needed.
         The team does step 3 again, holding up cards simultaneously

Planning poker ensures that people are thinking independently and proposing their estimates simultaneously. Requiring that all participants show their cards at the same time prevents those with stronger opinions from influencing others in the room. 

The best place to get planning poker decks is from Mountain Goat: http://store.mountaingoatsoftware.com. Each deck costs about $5.

Capacity and Velocity

Tracking the number of Story Points that a team can accomplish during their Iterations (Sprints) helps the team determine these two factors:

  • Capacity: How much work they can realistically finish during a given time frame
  • Velocity: How much work they can accomplish, on average, over time

Understanding these factors is very empowering to a team. And it is essential for estimating how much time it will take to release new features and deliver value to the customer. 

More Information on Using Story Points

Numeric Sequences, T-Shirt Sizes, and Dog Breeds, Oh My

There are other methods for estimating effort, including the following:

  • Numeric Sequences, e.g., 1 through 10 
  • T-shirt Sizes: XS, S, M, L, XL, XXL, XXXL
  • Dog breeds. Yes, that's right, dog breeds. This this method, a Teacup Chihuahua could represent the smallest stories, and a Great Dane could represent the largest. 

The important thing is that every member of the team is comfortable with the scale it is using and understands the scale’s values.

More Information on Alternative Methods of Estimating

  • No labels