Track Progress Effectively
now browsing by tag
by Kent McDonald
A while ago I shared three steps for more effective projects, based on the premise that it’s much better to be effective (do the right things) than efficient (do things quickly).
One of those steps is to measure success and progress based on outcome, not output. You want to use business objectives as a way of gauging success. This is often difficult, which is why teams don’t do it.
So what do you do if you would like to track progress based on outcome, but the outcome measure requires changes to be in production for a couple months before you see any results?
Or perhaps your stakeholders believe in the power of burn-up or burn-down charts to gauge progress. You know there’s got to be a better way, but you aren’t sure what it is.
Take it to the parking lot.
No, I’m not suggesting that you ask your stakeholders to go outside to settle things.
I am suggesting that you use a grossly underused technique called the parking lot diagram.
The Problem with Burn-Down Charts
As Agile came into vogue over the past 17 years, it dragged along with it several practices that have their good points and their bad points. The burn-down chart is one of those practices. Many Agile coaches swear by it, even though it introduces several concerns.
The concept of the burn-down chart is fairly simple: plot the team’s remaining work against the remaining time. The units of measure on the burn-down chart vary with the level of granularity you’re looking at.
If you’re doing a burn-down chart against a sprint, the work remaining is expressed in terms of estimated remaining hours, and the time is expressed in days in the sprint.
If you’re doing a burn-down chart against a release, the work remaining is expressed in terms of story points or stories in the backlog, and the time is expressed in number of sprints.
A good burn-down chart has a line that slopes down and to the right.
A fake burn-down chart has a perfectly straight line that slopes down and to the right.
There are three big concerns with burn-down charts. (There are more, but I’ll focus on the ones that help me tell my story.)
- They don’t give you much information as to why the number of remaining hours, points, or stories changed. Did the team add more stories to the backlog? Did the team not get anything done? Did the team take some stories off the backlog?
- They don’t tell you which backlog items were completed. You don’t know whether the team worked on the right things.
- They measure output.
Burn-Up Charts Are Better, Barely
An extension of the burn-down chart is the burn-up chart. In this technique, the chart has two lines. One line represents the total backlog, regardless of status. The other line represents the amount of work that has been delivered.
Burn-up charts tend to chart work in terms of points or stories and do not indicate hours remaining.
Burn-up charts provide information because now you can tell whether items have been added to or removed from the backlog.
Burn-up charts still don’t tell you which backlog items were completed so you’re no closer to knowing whether your team has worked on the right things.
Burn-up charts still measure output.
Parking Lot Diagrams Can Point You to Outcome
Parking lot diagrams were originally created to convey the status of projects using Feature-Driven Development (FDD), but they’re useful in any framework as long as your backlog is somewhat hierarchical.
You can think of the big boxes as key business areas the product supports (for example, Order Processing), and the smaller boxes as the epics the team is working on to support specific activities (for example, Create New Order).
For each epic, you can see the total number of stories related to the epic and how many are done. In this example, there are nine stories finished out of 12 stories identified for the epic.
Parking lot diagrams address the lack of context issue with burn-up and burn-down charts by showing the progress of specific epics and aspects of the product, rather than just an aggregated view of the overall backlog.
On the surface, the parking lot diagram still measures output. At the same time, it bridges output and outcome by providing context and introducing human judgment.
Let’s assume you organize your backlog items so they represent direct impact on your desired outcome. Because the parking lot diagram shows progress toward specific epics, it’s easier to know whether your team has completed the stories that will drive completion of an epic — which, hopefully, result in the desired outcomes.
Applying human judgment to determine the color status of an epic drives a closer tie to outcome. Notice in the key above that the Item Details epic is done, even though only nine of the total 12 possible stories are complete. In this case, the product owner determined that delivering the nine completed stories is sufficient to realize the expected outcome from the epic. You’re not using hard-and-fast algorithms to determine whether the epic is done, you’re gauging it based on the functionality you see as a result of delivering some of the stories.
It’s not exactly outcome, but it does provide more context to your measure of output. And it’s a useful leading indicator until you can measure the actual impact to your business objective.
Making the Parking Lot Diagram Effective
The parking lot diagram is an effective way to track progress when you use it properly.
Proper use means the diagram is used to quickly convey status to people outside the team.
Proper use means that those people treat the status indicated on the parking lot diagram as an indication for further exploration rather than a red flare that incites punishment or blame. If marking an epic at-risk incites punishment, epics won’t be marked at-risk … until it’s too late.
Proper use means that an organization recognizes that the right things have been completed to achieve the desired outcome, so they stop work on those areas and move on to a different problem.