Reasons to Disable Your Tool’s Estimates vs. Actuals, Ideal Line, and Individual Burndown Charts

Organizations that are looking for an automated tool to help manage Scrum fall along a continuum.

  • At one end are the Scrum purists, who feel that resistance to doing real Scrum is an organizational impediment to be exposed and rooted out rather than accommodated as business as usual. These folks believe the highest performance and ingenuity comes from intense collaboration, small cross-functional teams lacking defined roles, self-organization, face-to-face communication, and even a certain amount of chaos during Sprint execution. They typically prefer lightweight tools that make the Scrum artifacts visible without impeding team self-organization.
  • At the other end are those who want some version of the Scrum/agile practices, but also feel “traditional” practices (such as Taylorism, waterfall, or parts of the PMBOK) would meet their current needs. They may be dealing with impediments to self-organization, lack of co-location, suboptimal team composition, large departments, entrenched practices, regulatory requirements, etc. Or they may not be in a position to wait for teams to go through the “forming, storming, norming, performing” growth stages. These folks tend to request features that make the purists cringe.
  • Some are in organizations that are transitioning from traditional practices to Scrum. Some skeptics I’ve known became full-fledged advocates after seeing results from pilot teams attempting uncompromised Scrum with good coaching.

As someone who’s seen the power of uncompromised Scrum firsthand, I feel our job is to give you the tools you need today while nudging you to use them in a way that unlocks what your team is really capable of. If your existing practices are working fine, read no further. If not, consider this article a nudge.

Why not compare task estimates to actuals?

In Frederick Taylor’s world of Scientific Management, people engage in repetitious and/or procedural work that requires their bodies more than their imaginations. In a repetitious world we can make accurate predictions down to the daily or hourly task level, and reasonably conclude something is wrong when the actual doesn’t line up with the estimate.

Scrum/agile approaches are intended for complex work that is inherently unpredictable down at the hourly task level. If our hourly activities are inherently unpredictable and we’re being judged by how well our actuals match our estimates, we’ll feel pressure to:

  1. pad our estimates,
  2. decline to give estimates without extensive analysis,
  3. lie (perhaps even to ourselves) about our actuals,
  4. compromise the definition of “done” when allotted time runs out,
  5. decline to take on difficult, risky tasks, or
  6. blame others.

Can micromeasurement really invite micromanagement? A famous Scrum pioneer recently reported a large web sales company losing 50% of total production from their hourly reporting system — not because of the time spent filling out forms, but because of the perversion of behavior to look good on the forms.

You’ll have to decide for yourself whether your work fits more into the space where reality follows plans, or the one where plans follow reality. Most projects have a blend of both kinds of work. New product development, a kind of inventing requiring human imagination and team ingenuity, probably fits into the second category more than the first.

Why not draw an “ideal line” on the burndown?

The “ideal line” some well-intentioned people like to draw for the Sprint Burndown Chart is another subtle force against the transparency required for collaboration. As Kane Mar has written, a high-performing team can expect the Sprint Burndown to go up before it goes down because (in the complex realm) it’s impossible to predict all contingencies before beginning the actual work. The task discovery, including detailed requirements analysis, is part of the Sprint’s work. In The Enterprise and Scrum, Ken Schwaber writes “Many are developed during the Sprint Planning Meeting, but up to 40 percent might emerge during the Sprint.”

The “ideal line” (which Kane Mar refers to as “The Fakey-Fakey”) is not ideal at all, and may actually suggest a combination of padding and self deception. If you’re using a tool that draws this line, consider disabling that feature to reduce its anchoring effect.

Why show the weekend on the burndown?

Have you ever struggled with a difficult problem all evening, then solved it easily the next morning? Your subconscious mind works weekends too, and you may find it useful to see breakthroughs that occur after the team has rested. Also see “ideal line” discussion above — why does seeing a bumpy line make you uncomfortable?

Why not focus on “individual burndown charts”?

Another flavor of misapplied Taylorism is the “individual burndown chart” — a perversion of Ken Schwaber’s intended burndown chart that shows lines for each individual rather than the whole team together. A high performing Scrum team is characterized by people collaborating (or “swarming”) on tasks. Tasks have point people as primary champions to ensure they get done, but they’re owned by the entire team. As a senior developer, sometimes the best thing I can do for my team is mentor less experienced people with their tasks. An “individual burndown chart” would certainly discourage me from doing this. The last person I talked to using this feature described a “race” between developers to finish their tasks, then no one taking responsibility for testing and overall quality. If this is happening to you, consider disabling individual burndowns. Redirect focus to the whole team’s work, particularly the story acceptance criteria.

Is there any good news?

It may be painful to accept the inherent unpredictability of complex work at the micro level. But remember, your competitors are facing the same challenges. Letting go of attachment, unsticking your compass needle before they do, can give you an edge.

It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.
–Charles Darwin

Here’s more good news: At the macro level, some predictability does emerge. I describe a proven method to nail delivery dates by looking at the big picture here Macromeasurements Whitepaper.


Michael James
Software Process Mentor

SprintBurndown.png12.38 KB

Download the PDF version: Reasons to Disable Your Tool’s Estimates v Actuals blog

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile
6 comments on “Reasons to Disable Your Tool’s Estimates vs. Actuals, Ideal Line, and Individual Burndown Charts
  1. Willi says:

    So, Michael,

    What can we do when the customer asks for long term estimates for finishing the project?

    We just say it’s unpredictable?

    That’s gonna be hard to sell.

    Despite agreeing with you that this is unpredictable, we also should see the customer’s side.


  2. Michael James says:

    I agree the customer deserves the best information we can give about long term predictions. I describe an approach I’ve actually seen work (because it’s based on empirical measurements) here:

    For a more thorough treatment, I suggest Mike Cohn’s book _Agile Estimation and Planning_. ScrumWorks was designed to support these practices, which are becoming standard approaches.

    The chaos and unpredictability at the micro level does seem to smooth out at the macro level, kind of how objects <a href=””move randomly under a microscope but move predictably when we zoom out.


  3. BrianBurdick says:

    HI Michael,

    I understand your points regarding anchoring, the non-linear nature of sprint progress, etc. I Still like to see the trendline for some kind of visual reference. I find myseful imagining the trend line anyway. I don’t get to stressed out if I am way above it in the first half of the sprint. I would kindly ask that you at least make it an option – even if by default it is off. Also – it seems with the data that you have from previous sprints in each organization, that you could create an ideal curve based on the curves of previously completed sprints for the organization – a kind of best fit average burndown curve. This might more accurately reflect progress. It seems the data is already there in the product burndown – it just needs to be used per sprint as a curve.

  4. Michael James says:


    I can see why you might want to do that, especially for a longer Sprint, or in cases the work does fit the more predictable pattern. Another cool idea might be to show “ghost lines” from the team’s previous Sprints.

    ScrumWorks Pro is released several times per year. Feature requests can be submitted to Victor Szalvay (ScrumWorks Product Owner) here:


  5. Michael James says:

    [reposted from by mj]

    Re: [scrumdevelopment] Per Person Burndown Poll Doesn’t Make Sense

    Hello, captwilco2002. On Monday, August 11, 2008, at 12:11:21 PM,
    you wrote:

    > 1. Why doesn’t the poll make sense?

    Because …
    … per person tracking is counter-productive;
    … per person tracking does not collect useful data;
    … burndown is measured in things done, not time spent;
    … people don’t burn things down, teams do.

    > 2. Do you think I should be tracking this?

    No. Not remotely.

    > 3. About how many hours can be expected for an individual to burndown
    > in one day (on average)? (Not what is a reasonable number of hours to
    > expect each person to burndown on a daily basis, hence the purpose of
    > my poll)

    What is the difference between an average number that can be
    expected, and a reasonable number to expect?

    But never mind. Tracking individual hours of anything will break
    Scrum, or any other process.

    Ron Jeffries
    I once had a coworker who worked so hard that when I came in the
    morning, he was already sitting there trying to fix the things he
    broke after I left the day before … — Ilja Preuss.

Leave a Reply

Your email address will not be published. Required fields are marked *