Distance Remaining Is More Important than Distance Covered

Ancient sailors had two problems. First, they had to know their latitude; that is, their north-south position on a map. Second, they had to know their longitude, or east-west position. Determining latitude by observing the North Star was relatively easy and had been done as early as 300 B.C. Longitude presented a more difficult problem because it relied on the use of a relatively accurate clock, or chronometer. Unfortunately, there were no sufficiently accurate chronometers (especially that would fit and work aboard a ship) until the early 18th century.

Before the invention of the chronometer, a sailor could only guess at his longitude. To do so, sailors applied a series of guesses and adjustments known as "dead reckoning,” which involved guessing how far east or west a ship had sailed and then adjusting that guess by estimates at the impact of the wind and the drift of the sea. Suppose, for example, that the speedometer on your yacht says you are traveling eight miles per hour. But if you are heading into waves, wind, and current, you may make only five miles per hour of progress. Your dead reckoning guesses must reflect this smaller amount, or your longitude estimate will be incorrect.

What today’s software project managers can learn from these ancient mariners is that it is more important to know the distance remaining to a destination than to know the distance traveled. Tracking the progress of a software team is similar to charting a ship's position, especially by dead reckoning. We would like to sail our software development project in a straight line from point A to point B. This rarely happens, though, because requirements emerge and are refined, our rate of progress isn't always what we expect, and we sometimes make mistakes in how we measure our position.

At the beginning of a an agile project, the team establishes a plan that says something like, "Over the next four months (comprising eight two-week iterations), we will complete approximately 240 story points of work." At the end of each iteration, an agile team assesses its position. However, there are many forces at work, and we need to consider each. First, and ideally most significant, is the amount of progress made by the team.

Second is that developers may have learned things during an iteration that prompt them to revise their estimates for work coming later in the release plan. It may be that some work they anticipated to be easy, they now think will be difficult.

A third force is any change in the scope of the project. The product manager may have added or removed requirements during the iteration. If the product manager added 40 story points and the developers completed 30, the total work remaining at the end of the iteration is more than at the beginning of the iteration. A team in this situation has sailed into a headwind.

In a situation such as this, it may appear that the team has moved further away from their destination; after all, there is now more work to do. However, I contend that the team has moved closer to its destination. A software development team should not view its destination as the delivery of a product that exactly matches a preconceived, supposedly complete specification. Completely and precisely specifying a product is an impossible goal. Every product includes some amount of emergent requirements; those requirements that our users and customers can think of only once they begin to see the product take shape.

An agile project team must instead view its destination as delivering the optimal product that can be built within specific resource and schedule constraints. Because the exact feature set of the optimal product is unknown at the start of a project, an agile team focuses both on delivering new capabilities and on generating knowledge that reduces the uncertainty around exactly what the optimal product entails.

If a product manager adds forty story points of work to a project, she presumably does so because that redirects the team toward the delivery of a more valuable product. In an ideal world, the product manager would find an equivalent amount of work to remove from a project. Often, however, this is not the case and the pursuit of the optimal product may mean an increase in the scope of the project.

Because a team's ultimate destination will almost certainly move over the course of a project, it is important to measure how close the team is to their current destination rather than how far they've come since the start of the project. The best way I’ve found for doing this is to use a release burndown chart. A release burndown chart is a simple line chart with time across its horizontal axis and story points (or a similar measure of size) on the vertical axis. An example is shown below.

At the end of each iteration, the amount of work remaining is calculated and plotted as a new point on the chart. This has the effect of charting a team’s net overall progress—two steps forward and one step back net out to one step forward. A team that completes thirty story points of work during an iteration will add a new point on the chart thirty points lower than the previous point. A team that completes thirty points but whose product manager adds forty will have experienced a net increase. A point will be added to the burndown chart ten points higher than the previous point. The way this works is analogous to navigating by dead reckoning: a team estimates its forward progress (work completed) and then adjusts for changed estimates or added work. And, like sailors of old, projects will benefit from paying attention to how far they are from their goals rather than how far they’ve come.