Channels ▼


Accurate Project Estimation

Effective estimation is one of the toughest challenges software engineers face in their jobs. Regardless of team size, it's important to crisply define, estimate, and distribute work throughout a team. As teams get larger, it becomes even more important to build good habits around planning and estimating work. Lack of planning and estimating reduce confidence in a program, breaks down relationships between the team and the business, and makes development harder on everyone. In this article, I offer techniques to make estimating easier and show how to build trust across teams in those estimates.

Let's start with defining a unit of work. Agile teams use terms like epic and user story, traditional teams may use task or feature, and all software teams use the term bug! I'm going to define work as a change from the current state that requires effort from one or more people to deliver. Properly defined work also includes clear metrics for success, so the team knows when work is complete.

Start with a Product Roadmap

Every team needs to build a roadmap. It's critically important to the development team to understand how the code base will evolve over time. The roadmap will likely have four to six major initiatives. Each initiative will have several large features inside of it. Each feature will likely have multiple components. And each component will require a set of tasks and user stories needed for delivery.

It's important to break down each component into a series of 8- to 16-hour tasks. The most effective estimation sessions involve the entire team. As a team plans, questions about how individual streams of work fit together will arise. This is a good thing. These questions foster organic conversations about the project and minimize surprises. If a team is new to estimating together, start with at least the product owner, Scrum Master, and the development team (dev and test engineers).

You're probably thinking, "I can't do that level of detailed estimation for my entire roadmap!" You're absolutely right. You shouldn't. Focus on doing detailed estimation for only the first few items in the feature pipeline. Once the team understands the effort required to deliver the first few items, it can more broadly forecast the scope of work for items deeper in the backlog. This highlights a key rule of thumb: Accuracy of estimates declines as the scope of work gets larger.

Minimize Waste by Using a Backlog

By using a backlog, agile teams enjoy more flexibility in planning and delivery. A backlog of work is simply an agreed upon way for a team and business to prioritize work. The most important item is on the top of the backlog. Items are then listed in decreasing priority, walking down the backlog. As a team completes items at the top, they move on to the next item on the list.

Over the course of the project, business priorities will change. Product owners can easily move items in the backlog that the team is not working on. The team is not impacted and everyone remains focused on the goals ahead.

The Case for Relative Estimation

To get started, I strongly recommend using relative estimation. I learned the practice of using story points in scrum training. Story pointing assigns Fibonacci values (1, 2, 3, 5, 8, 13, etc.) rather than time estimates to bodies of work. Let's take a simple example: Imagine trying to estimate the relative complexity of fully consuming a piece of fruit. The first item in the backlog is to eat an apple. We assign that a story point value of 2. When looking at the next item, a banana, we know it's at least as complex as an apple, but with the additional cost of having to peel it. Let's give the banana a 3. Oranges are more complex, so we assign a 5. Once we eat another piece of fruit, we can compare the experience to eating an apple retrospectively. We then reconfirm estimates for both experiences. If eating a fruit is significantly harder than we estimated, this is a key learning and we make adjustments. Understanding learnings throughout the process helps improve a culture of estimation.

So why use story points instead of time values? Story pointing allows the team to focus on the complexity and time involved in delivering a piece of work. The team compares the new work against work they've already done. They compare the complexity of the new assignment against past challenges and rank the difficulty as well as the time required.

With time values, we don't often account for "the cost of doing business." Meetings, email, code reviews, etc. — all are necessary practices throughout the workday, but don't actually count as "work." Story points isolate the workstream from the non-workstream items, so estimates are more consistent.

Finally, a team's process evolves over time. As the team incorporates better development practices, its ability to deliver work increases. Story points focus on the complexity of work versus just the duration, and they are more resistant to change. Likewise, if a team's definition of done changes, story points hold better over time.

Estimates are Self-Evident

In software teams, there is a lot of fear around estimates that "grow legs." We've all been on a project where it's proclaimed, "This feature will take three months to build," which really means "Commit to delivering this feature in three months regardless of cost." This sets up the potential for failure and missed deadlines. While there is comfort in locking schedules down, it limits a business's ability to make the right decisions as the program evolves.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.



"Consistent velocity unlocks the power of estimating larger bodies of work." -- This is the key that has worked for us. For years in both government/military and the corporate world the mantra was break it into details and cost it out. This approach, for the vast majority, consistently resulted in late and buggy projects (yes, they did the "do it in half that time" routine regularly).

Instead, when we simply looked at our past history and saw things like averages of 18 months to launch a new product we knew we had a better idea. We just picked our historical average and said that is how long it would take. The initial reaction was "No way! Why so long?!" which is humorous because the typical "plan" was something like 12-15 months even though the average performance was 18 months (and *never* 15 or less).

I never saw much in Agile I cared for (hated the notion of pair programming) but when I saw Scrum and then saw it using the velocity concept (a historical average) I fell in love with it.

Bottom line, it isn't the analysis of the details that made the difference, it was knowing our actual historical past performance and using that recent past performance as our project estimate. We then never delivered a project more than two weeks late and have been up to a month early.

Ref 1: Its The Schedule:
Ref 2: Its Not The Requirements:


Why the anger? The author is describing what's worked for him and specifically recommends Scrum as a way of implementing getting good results with these techniques.

However, he is very definitely not describing Scrum, which is a much larger systemic approach to a different problem. Sites that don't use Scrum but need better estimation will surely find value in knowing these best practices.

Glad you mentioned McConnell's book (which actually came out in 2006), "Software Estimation:Demystifying the Black Art." Indeed, it covers some of the ground covered here and makes a good follow-on text for readers looking for more information.


This guy just described scrum. Steve McConnell's book on project estimation from 1999 or so discusses this stuff in detail. So a pretty sad article.


It is "easy" to estimate time for individual software modules. One hard problem, which always occurs, is estimating time for integration...


"By decomposing work
into small tasks, accurately assigning points to those tasks, ...."
Any advice on how to accurately estimate the time it will take to decompose work into small tasks?