E-MailSoftware Project "Dead Reckoning"
"Software project managers would like to sail software development projects in a straight line from point A to point B. This rarely happens, though, because requirements emerge and are refined, their rate of progress isn't always what they expect, and they sometimes make mistakes in how they measure their position," says Cutter Consortium Senior Consultant Mike Cohn.
Before the invention of the chronometer, ancient sailors could only guess at their 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.
"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," says Cohn.
At the beginning of 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.
According to Cohn 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."
Because it may appear that the team has moved further away from their destination, it is more important to measure how close the team is to its current destination rather than how far it's come since the start of the project.
Cohn's suggestion 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.
"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 30 story points of work during an iteration will add a new point on the chart 30 points lower than the previous point. A team that completes 30 points but whose product manager adds 40 will have experienced a net increase. A point will be added to the burndown chart 10 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."
To request the Agile Software Development & Project Management Advisor in which these comments were made or to schedule an interview with Mike Cohn, contact Ron Pulicari (+1 781 641 5114) or e-mail at press@cutter.com.
More information about Mike Cohn is available at http://www.cutter.com/meet-our-experts/cohnm.html.