Agile Advisor

Remaining Work is Key for Agile

Aaron Bjork talks about why remaining work is the most important measurement on your Agile projects.

• By Aaron Bjork
• 12/07/2011

Last summer I took a road trip with my family East of the Cascade Mountains here in Washington State.  We had a six-hour drive ahead of us before arriving at our destination.  For those of you with families, you know that six hours is a long time in the car. At the time, my kids were ages 6, 7 and 9. On this particular trip we'd been on the road for roughly 30 minutes when my 6-year-old daughter, Lily, asked the question every parent knows all too well… "Are we there yet?"  I responded calmly, "No, we're not there yet." To which Lily quickly replied, "How much further?"  It's a conversation I'm sure every parent has had. 

After the trip I reflected on the interaction with my daughter and realized an important parallel to tracking work on software projects.  You see, my response to Lily was quite simple.  When she asked how much further we had to drive, I gave her my best estimate of the amount of drive time remaining on our car trip: five hours. Not surprisingly, she wasn't particularly happy with this response; five hours is a long time for a 6-year-old. At the same time, the answer was satisfactory because it properly set her expectations for what lie ahead. She might not like the fact that we have five hours remaining in the car, but at least she's informed and can anticipate the rest of the afternoon.

Now, our conversation would have been completely different had I responded to her question by stating "We have traveled for 30 minutes so far."  She likely would have stared at me with a confused look on her face.  She's not particularly interested in how far we've travelled.  It doesn't answer her question.  She wants to know when we will arrive at our destination. She's interested in how much longer she has to sit in the car. A response of this nature emphasizes our effort (30 minutes of driving), but doesn't leave her with any reasonable understanding of when we will arrive. Will we drive for another hour? Another ten hours? 

Software teams have similar conversations when discussing the remaining work on tasks. Every software team I know estimates their work as a part of planning. It's an important and essential part of the process. The estimate provides a data point that can be used to start measuring progress. Without the estimate, the team is flying blind. I see many teams, however, overemphasizing estimates, all the while underemphasizing the most important data point -- remaining work.

Most teams are conditioned to track three pieces of data:

1. Original estimates
2. The amount of work completed
3. The amount of work remaining

I believe there's a place for all three of these data points in a project, but I would argue that only one these pieces of data really matters -- remaining work. Why? Remaining work is the only data point that helps the team understand how far they are from the finish line. 

Estimates.  Let's start with tracking estimates. The common argument for tracking original estimates is that it helps the team over time improve their ability to estimate. It's quite common to want to look back at how much time was estimated for each task and compare it with time spent toward completing the task. The problem with this approach is that it shifts the emphasis to the accuracy of the estimate, instead of the completion of the task.

Agile tells us that things will change after we start. It's an expected part of the process. To that end, estimates shouldn't be expected to be perfect. Remember: the goal is to be done with the project and deliver value to customers. The goal is not to produce perfect estimates.

I'm not arguing to throw away estimates or do a poor job of creating them. Rather I'm arguing that once an estimate is created, the team should turn its attention to remaining work. The estimate is just a starting point for how much work remains.

Completed Work. Similarly, most teams have an initial allergic reaction to letting go of completed work. They've tracked it closely for years and are programmed to care about it. The reality is that tracking completed work doesn't matter to the success of the project. It makes no difference that a team completed 100 hours of work, if 150 hours are needed to meet its commitment. The remaining 50 hours are what is important.

Overemphasizing completed work can lead to a dangerous game where the team begins to focus on its effort rather than its result. Again, I'm not arguing that tracking what's done isn't important. Teams should absolutely track what they're accomplishing and celebrate the completion of each item on the backlog. But don't let the tracking of effort on tasks confuse the team about its goal.

Let's return to my family road trip last summer. In the end, it took us almost seven hours to complete the drive to our destination. When we arrived, we were all elated and ready to start our vacation in earnest. Nobody cared that my five-hour estimate had been a little off. We had decided mid-trip to stop for a longer lunch and to take in a few sights along the way. Things changed after we started, and we reacted to those changes accordingly. What mattered was that we had arrived.