Creating a production timeline is an important milestone. It provides a roadmap for the team, identifies who will complete each requirement, and estimates when the work should be finished.

Unfortunately, software projects rarely unfold exactly as planned.

Unexpected bugs appear. New requirements emerge. Estimates prove inaccurate. Team members become unavailable. Even the most carefully constructed timeline will almost certainly need to change as development progresses.

Rather than expecting the plan to remain perfect, successful software teams expect change and monitor their progress so they can respond quickly when problems arise.

Two tools are commonly used to support this process:

• Burndown Charts, which measure progress over time.
• The Big Board, which helps the team organize and coordinate their daily work.

Together, these tools provide a clear picture of where the project stands and whether the team is likely to meet its goals.

What Is a Burndown Chart?

A burndown chart is a visual representation of how much work remains in an iteration.

The horizontal axis represents time, usually the working days within an iteration.

The vertical axis represents the amount of work remaining. This might be measured in productive working days, hours, story points, or another unit chosen by the team.

Regardless of the unit, the purpose remains the same:

A burndown chart helps the team compare the work they planned to complete with the work they have actually completed.

The Ideal Burndown

At the beginning of an iteration, the team estimates the total amount of work that must be completed.

For example, consider a team of five developers working for a 20-day iteration with an expected velocity of 70%.

The team has:

• 5 developers,
• 20 working days,
• a productivity rate of 70%.

This means the team can reasonably expect to complete 70 productive working days of effort during the iteration.

An ideal burndown line is created by drawing a straight line from:

• the total amount of remaining work on Day 0, to
• zero remaining work on the final day of the iteration.

This line represents the pace the team hopes to maintain throughout development.

Tracking Actual Progress

At the end of each working day, the team determines how much work has actually been completed.

Suppose the team completes only 2 productive working days of work on Day 1.

Since 70 productive working days were originally required, 68 productive working days now remain.

A point is added to the burndown chart at Day 1, 68 days remaining, and connected to the previous point.

Repeating this process each day creates the actual burndown line.

Comparing the actual line with the ideal line quickly reveals whether the team is:

• progressing as expected,
• falling behind schedule, or
• completing work faster than anticipated.

Rather than waiting until the end of the iteration to discover problems, the team can identify issues early and adjust their plan while there is still time to respond.

Understanding Velocity

A team’s velocity describes how quickly it completes work.

The expected velocity is established during planning based on factors such as:

• team size,
• developer experience,
• historical performance, and
• the amount of time available for productive work.

The burndown chart allows the team to compare this expected velocity with their actual progress.

If production is consistently slower than expected, the team should discuss why.

Possible reasons might include:

• inaccurate estimates,
• unexpected technical challenges,
• missing requirements,
• interruptions or distractions,
• blocked tasks, or
• dependencies that were overlooked during planning.

The goal is not to assign blame.

Instead, the burndown chart helps the team identify obstacles early so they can adapt before small problems become large ones.

Reading A Burndown Chart

When interpreting a completed burndown chart, consider questions such as:

• When was the team progressing more slowly than expected?
• When did productivity improve?
• Did the team complete all planned work by the end of the iteration?
• Are there sudden changes that suggest unexpected events or newly discovered work?

These discussions often provide valuable insights that improve planning during future iterations.

The Big Board

While a burndown chart summarizes overall progress, teams also need a way to organize the work that is currently underway.

Many teams use a visual planning board known as The Big Board.

Although different organizations use different names, the underlying idea remains the same: provide a shared view of the work so everyone understands the current state of the project.

A typical Big Board includes:

• the current iteration,
• the requirements or user stories scheduled for that iteration,
• the tasks associated with each requirement,
• a To Do section,
• an In Progress section,
• a Completed section,
• a Parking Lot for newly discovered work, and
• the team’s burndown chart.

Many teams also use coloured sticky notes to distinguish different types of work, such as user interface development, database work, APIs, testing, or documentation.

Because the board is visible to everyone, it becomes a central point for communication throughout the iteration.

Managing Work

As work progresses, tasks move across the board.

Tasks begin in To Do.

Once a developer starts working on a task, it moves to In Progress.

After the task has been completed and reviewed, it moves to Completed.

Many teams encourage developers to work on only one task at a time. Limiting work in progress helps maintain focus, reduces partially completed work, and makes bottlenecks much easier to identify.

If new requirements or unexpected tasks are discovered during development, they are placed in the Parking Lot until the team decides whether they should be included in the current iteration or scheduled for a future one.

When Is a Requirement Finished?

Knowing when a requirement is complete is just as important as knowing when development has started.

Different organizations define “finished” differently, but many teams expect questions such as these to be answered before a requirement is considered complete:

• Has all required functionality been implemented?
• Have the necessary unit tests been written?
• Do all tests pass successfully?
• Has the code been reviewed?
• Have any important performance or memory issues been addressed?

Some organizations rely on a product owner or team lead to approve completed work, while others make this decision collectively as a team.

Regardless of the process, well-written and measurable requirements make it much easier to determine whether a requirement has truly been completed.

Looking Ahead

Planning, estimating, organizing work, and monitoring progress all help software teams stay on track.

However, even with these tools, software development remains an iterative process. Teams continually learn, revise their plans, and improve both the product and the way they work together.

The goal is not to follow the original plan perfectly.

The goal is to deliver valuable software while adapting effectively to the inevitable changes that occur throughout development.