"The frequent interactive exercises and case studies to reenforce the concepts made the 2-day Scrum course valuable and enjoyable."
- Benjamin Cohen, PayPal, Inc.

>> Read more testimonials



Subscribe to Scrum Users

ScrumDevelopment Archive
Work Burn-Down

Management is concerned about :

  • Sprint progress - how is the team doing toward meeting their Sprint goal?
  • Release progress - will the release be on time with the quality and functionality desired?
  • Product progress - how is the product filling out compared to what's needed?

Ê To answer these questions, you can assess Product Backlog, Release Backlog (product backlog that has been identified as required for the next release of the product), and Sprint Backlog contents and trends.

Each backlog item contains the amount of work remaining. These values are updated continuously. Plot this backlog across time. Even though you might think that backlog should always go down, new work is always being discovered as the product is being built. Expect the backlog to go up and down.

Plot the slope of the backlog. If you draw a line representing average slope over a period of time, you can project it to determine when no work is likely to be left (mission accomplished, Sprint goal reached, or release ready for finalizing). Team velocity=actual work completed/days to complete.

Manage empirically so that Sprint backlog and Release backlog reach zero when needed. You do this primarily by adjusting Sprint and Release contents or by modifying the Release date.

This type of management produces "the best possible software". The team is doing what they can and you are helping them as much as you can.

Every team has different signatures. Backlog trends and velocity represent these team signatures. You'll learn these signatures and be able to help teams adjust accordingly. For instance, some teams always have Sprint backlog that keeps going up during the first tpart of the Sprint, and then descends dramatically. Assess the measurements and determine whether this is because of inadequate Sprint planning, overwork during the last ten days (usually causes poor quality), or infrequent reporting of work remaining.

Each team member is responsible for estimating the number of hours remaining to complete all assigned tasks during a Sprint. As work is completed, new estimates (hours-effort remaining) are made until all work is completed.Ê These estimates are then summarized for all tasks and converted to a burndown chart which can be used to determine overall progress being made during the Sprint.

The Product Manager is responsible for maintaining Product Backlog, along with estimates for how much work is required for a backlog item. As Sprints build product, the Product Manager re-estimates (sometimes the feature is only partially implemented) or zero's (feature completed) backlog items.

Work remaining reporting during a Sprint focuses on updates to the estimated number of hoursÊ to complete a task. This should not be confused with time reporting. At the beginning of the Sprint, each team member estimates the number of hours it will take to complete each of the tasks that they have been assigned for the Sprint period.Ê As the work is completed, a new estimate to complete is made for each task.Ê This process continues on a periodic basis until all tasks are finished during the Sprint.