Channels ▼
RSS

Design

Accurate Project Estimation


The hallmark of an agile organization is its ability to navigate and prosper through change. Estimates will shift. What's important is focusing a development team and business team on the backlog. The product owner is responsible for maximizing the development team's value. Estimates from the development team help the product owner determine the cost of work and to prioritize work for delivery.

The development team's most strategic relationship is with the product owner. As the development team makes better estimates, the product owner can then more accurately plan the product roadmap. In turn, the product owner is less likely to engage in anti-patterns like mid-sprint additions that can increase context switching and thrash for the development team.

Why Trust is the Essential Glue

Estimation of software development work can't effectively happen without trust across an organization. From engineers to finance to marketing, we hire different teams of trained professionals because of their skill sets. It's important to keep working as an overall team and build trust among teams so that the best products and outcomes are delivered.

Unfortunately these types of conversations occur with some regularity:

"How long will it take to deliver feature X?"

"We think it's three months"

"I need it in two. Find a way to make it happen."

"uh…"

If the project scope doesn't change to accommodate the new delivery date, the development team learns that estimation doesn't matter. Engineers feel pressured to make shortcuts that affect product quality. Trust falls apart and the program can fail before it really begins. Everyone suffers.

The reality is that sometimes products do have a timeline to meet. Here are some questions to help spur productive conversation:

  • What is the most important part of this initiative? ("All of it" is not a real answer.)
  • Is there a way to decouple and parallelize the work across teams?
  • How can we get feedback earlier in the development cycle to ensure we have the right minimum viable product?

In rare cases, a particular stream of work just has to get done. Product owners and business leaders can push the team to put in extra hours — but it's important to realize, burnout drives down quality in the long run.

Empowering the product owner to focus engineering time on the right items frees everyone from the challenge of waterfall development. Rather than being constrained by time, the team is constrained by scope. Engineering capacity is a fixed entity that the product owner can use to deliver the product.

Build a Culture of Estimation

I mentioned earlier that you don't want to do detailed estimates for items further down in the backlog. Estimating a bunch of work that never gets completed is a waste of the team's time. As a team completes a milestone, take the time to review estimates with the actual time required for delivery.

If there's a significant difference, understand why in the retrospective. If any of the forecast estimates further out in the backlog may be impacted, take the time to update estimates. Having these conversations out in the open keeps everyone on the same page as the product evolves.

Get Started with Scrum

Getting started with something new can be challenging. I recommend focusing on learning story pointing inside of the Scrum framework. Focus on assigning story point values to individual items inside of the sprint. Keep track of how many story points the team accomplishes each sprint. After a couple of sprints, the team will settle into a velocity — the amount of story points the team can deliver over a fixed iteration.

Consistent velocity unlocks the power of estimating larger bodies of work. If a team can complete 50 story points per sprint, they can accomplish 500 story points over 10 iterations. Remember though, the key thing is to build estimation culture across the team. Learn when estimates are correct, and if there is a miss, take the time to understand why and use that learning going forward.


Dan Radigan is a Sr. Agile Evangelist at Atlassian, makers of JIRA. Prior to Atlassian, he was an engineering manager at Netflix. Follow him on Twitter @danradigan.


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.
 

Video