Putting Task Estimates in their Place

Let’s look at how a team makes use of task estimates. During Sprint Planning, teams create tasks and task estimates from the backlog items that they are potentially going to commit to finishing. Sometimes, these estimates have some effect on whether or not the team is actually going to commit to completing the backlog item, but most of the teams that I’ve worked with or interviewed told me that their team commits to backlog items based on what they “feel” they can accomplish, not based on the total hours that they’ve estimated so far. I coach this “how-much-does-it-feel-like” approach as well because I want a commitment based on the team’s willingness to commit, not one based on arbitrary mathematics.

How else do we use task estimates? Well, we update them every day – that’s where the Sprint Burndown comes from. The Sprint Burndown is a tool for the team to understand how much work we’ve gotten done this Sprint compared to how much we think is left. However, on a day-to-day basis, how much does the condition of the Sprint Burndown affect how your team members work? Do they work faster? I hope not – that’s when we cut corners on quality. Do they work longer hours? Again, I hope not – beyond a certain degree, individual team member performance will actually become worse. So, other than using the burndown to see if the team needs to de-commit something or take on a new story during the Sprint, the estimated remaining hours on each task is used to manage the commitment, not drive the work.

In fact, tasks only create a list of things to do, and tasks estimates serve little more than administrative purposes. Trying to gain an understanding of why some actuals were higher and some were lower will be scientifically impractical. What I mean, is that there are too many variables in play that effect how an individual and a team performs during a Sprint: individual skills, emotions, physical health that day, how focused they were, whether or not they manage a leap of intuition, etc. At the Sprint-level perspective, many of these “effects” average out; at the task-level, however, they are clearly in play. Rather than trying to figure out why your actuals were 12% off your estimates, do these three things:

  1. just ask your teams to commit to one or two fewer stories or one or two more stories next month,
  2. do not assign all of the tasks on the Sprint Backlog on day one. Team members should pick up the tasks they want when they are ready for the next task. They should break up into smaller teams, take the tasks they can do, and come back to the task board for more when they are ready.
  3. Use backlog grooming techniques to slice your backlog items into small pieces before the Sprint begins. Try to target getting items down to a size that two or three team members could finish a story in less than a week. That will improve the flexibility of your teams and will improve your teams’ ability to fine-tune their commitment from Sprint to Sprint.

Download the PDF version: Putting Task Estimates in their Place blog

Posted in Agile
5 comments on “Putting Task Estimates in their Place
  1. ajayaram says:

    There are various reasons for using tasks at the sprint level. Again it depends how the team uses to its benefit.
    Adding tasks in a sprint helps team get a sense of whether the committed BIs in a sprint can be accomplished. This is also used as a communication between distributed teams.
    I agree that actuals against estimate at the task level doesn’t make sense overall from the sprint or release prespecitve. But for a team member who wants to get better at planning or increase efficiency by automation on a similar type of task can be beneficial.
    I think there is some value to measure actuals against estimate at the points level. This is for the team to get better at estimating on similar kind of work. This should not be definitely used by management as a metric.
    I have few more questions on tasks and its allocations based on the team dynamics but I will post it later.

  2. Michael James says:

    I’ve been programming since the CP/M-80 days, and still haven’t gotten much better at estimating. I think this is true of all developers, but many are unwilling to admit this to themselves for fear of looking incompetent. (Similarly, we’re also reluctant to admit we can’t create a perfect architecture up front.)

    The only thing I can remember getting good at estimating was creating entity EJBs, because I was using the same “cookie cutter” approach for each one. Then I realized I could make a generic doodad to reduce gruntwork, and the estimates got unpredictable (though smaller) again.

    So maybe being too good at estimating something is a negative sign — a clue we should have automated it already. The opportunities are at the edge of chaos, not in the repetitious work.

    –mj

  3. Jim Schiel says:

    Ajayaram, I certainly wouldn’t argue that there’s never a benefit of tracking actuals in certain instances. As a Six Sigma Green Belt, I could definitely see the possibility for opportunitites in understanding where the team is spending too much time.

    And don’t get me wrong — I’m not arguing against tasks in the Sprint Backlog — that would be quite an obscure approach indeed. No, instead I’m simply suggesting that I’ve never, in 24 years, seen much opportunity in tracking actuals. Usually the circumstances from one “similar” task to another is so varied that it is quite difficult to isolate enough of the circumstantial effects to actually compare tasks.

    Indeed, if improving team performance is a goal, may I recommend Sprint Retrospectives where the team is asked how and if they feel they are wasting or losing time on specific types of tasks of even if they are routinely forgetting types of tasks that they should remember during Sprint Planning or adding tasks during Sprint Planning that they really don’t need. While I understand the possible use of task actuals in this scenario, I believe you’ll find a in-depth retrospective much more efficient.

    However you choose to proceed, good luck! I hope you get the same satisfaction from using Scrum as I’ve gotten over the past years.

    Jim

  4. PParker says:

    The recent teams I’ve worked with get wrapped up in hours estimated for each Sprint, over analysis can cause team paralysis. Management wants to ensure each person on the team is at full capacity during a Sprint and want the estimates to match hours available. Unfortunately, it is a reality in most organization that projects are capitalized and the hours spent working on task need to be captured for business reasons. Therefore, they look at the initial estimates as gospel (i.e. in the Waterfall tradition). Until a development organization can show true benefits from loosely coupling task hours and capacity will this problem be resolved.

    P.Parker

  5. jschiel says:

    P.Parker, thanks for your feedback.

    When I started posting a reply, it got quite long. So, I made it a new blog entry and posted it here.

Leave a Reply

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

*