Sprint Heartbeat: Visual Task Tracking

Continuing to think about visually tracking the health of a sprint, I advocate tracking at the task level, rather than the story level. Recall that my goals for a successful solution include:
  • Radiate information.
  • Clearly communicate whether the sprint is on track and likely to conclude successfully.
  • Alert us to lurking risks, so that the team can react and adapt proactively.
  • Tell a story about the sprint from which we can learn during our retrospective.

Instead of moving user stories through phases (development, review, testing...), list their tasks. Tasks for a story could include testing and reviewing pieces, merging code into previous versions, meeting with a product owner to review the UI and clarify requirements, or convening a design session. You can add tasks to the list as they are discovered, which can signal that a story is ballooning or that a technical problem is thornier than originally estimated. If there are certain steps the team is trying to get more rigorous about (like writing unit tests before writing code), you can list them as explicit tasks until they become second nature.

Each day, estimate the number of hours remaining in each task. Not the hours spent, and not a comparison of estimates to actuals. This is not about "metricking estimation accuracy" or some other useless bean counting; it is about ascertaining right now, today, how many hours' worth of work is there left to do, and will that fit in the time we have left.

The hours remaining on a task might go up. (Ever peel back the wainscoting on a piece of code and find it's all termites underneath?) New tasks might get added during the sprint. The reason to track the hours remaining is so that you can adjust when you spot a potential problem—perhaps a team member is getting pulled away with other work, or is stuck in a mess of code that your expertise could alleviate, or maybe it's time to negotiate a trade-off with your product owner. To deal with any of these effectively, you need to know, if you'll pardon the vernacular: Where we at?

Sample agile task list, tracking hours remaining for each task

In the sample task list above, you can see that we're not only showing the hours remaining, but also tracking the movement of that number day after day. That allows us to make a graph, creating that visual heartbeat we're looking for.

Sample sprint burndown chart, comparing each day's hours remaining against an optimal trend line

At the end of the day (or completion of a task), update tomorrow’s column for the number of hours remaining for that task. If you finish a task on Day 4, then at the start of Day 5, there are zero hours remaining for that task. New tasks that crop up unexpectedly should show a zero until the day on which they were discovered, and then an hours-remaining estimate until finished.

The graph plots each day's sum of estimated hours remaining. It also shows an idealized burndown line, as if the team were completing [original hours estimate / number of days] worth of work each day. This makes the picture clearly communicate whether you're in fair weather or potential trouble.

If estimating hours remaining seems daunting, split the tasks into smaller pieces. A task should fit within a day, and the work you claim in the morning stand-up should fit within a day.

Time tracking is a sensitive topic, and suggesting it may not be well received by the team. Despite good intentions, many organizations use time accounting policies abusively. Superstitious beliefs, uncharacteristic vehemence, and irrational resistance are indicators of prior abuse. There is a tension between the two Agile tenants of transparency and self-organizing teams: I don’t want to hide data from you, but if I let you see the tools we’re using to track our progress, you’re liable to interfere, draw wrong conclusions, or base bonuses and promotions on them. These are not flaws in tracking sprint progress, though; they are deeper organizational issues, that are worth correcting and rehabilitating so that the team can take advantage of a burndown chart's benefits.

A graph tracking your team's completion of work gives you a picture of the state of the sprint, making it easy to see if you're on track to succeed, and alerting you to struggles early enough to react.

Visible Sprint Status: Maybe Not Corkboards?

I'm thinking about ways to track the activity—the status... progress... stuff—that happens within a development sprint.

You could conceive a user story as moving through a series of phases (e.g., development, code review, testing, accepted). You might set up your Scrum task board using this paradigm, where you move an actual piece of paper between different columns on a corkboard. Some project-management software packages I've evaluated encourage a workflow of phases.

I wonder if there's a better way. At the user-story level, the idea of "passing through phases" seems Waterfall-ish, which always snags my attention because so few human endeavors are that linear. Phases lead you into some non-Agile patterns of thought, and they obfuscate the current health of the sprint.

Mike Cohn's task boards (with pictures!) divide into rows as well as columns. A row corresponds to a user story, and the tasks that compose that story move through the columns, which correspond to statuses. I'd previously missed (or forgotten) this distinction, and I thought the cards on the board were stories. I finally noticed the difference while drafting up this blog post, because I went looking for corroboration about the disadvantages of moving user stories through phases on your task board. What follows is an analysis of those disadvantages: non-Agile patterns and obfuscated sprint status.

By non-Agile patterns, I mean that columns on a board draw boundaries (literal and metaphorical) between collaborators. Do you intend to tell your testers that they can't think about a story until it lands in their column? Are you keeping your product owner from looking at a feature until all the code is built and blessed (and you've run out of time in the sprint)? Are you throwing code over the wall at people who might as well be in a different department?

"Heck no!" you cry. But doesn't a task board with indivisible user stories, sitting inertly in discrete statuses, imply that's what you're doing? Well, it could. And the metaphor subtly seeps into your thoughts and behavior, constraining your team's responsiveness, creativity, and collaboration.

How does a story-oriented task board obfuscate the status of your sprint? After all, it is tangible, visible, large-as-life where everybody can see it. But what is it telling you? Here are some challenges I've observed.

The pieces of paper representing user stories are the same physical size, but the effort required for different stories can vary dramatically. You glance at the board for a gut check, but you'll draw the wrong conclusion from lots of little stories (unnecessary worry) or few big stories (misplaced complacency). You could ameliorate this by making the pieces of paper represent component tasks instead of whole stories, but does a mere task move into the testing phase? Does your product owner evaluate a task? Can your customers use one? No, they need complete user stories. Once you've made the papers represent similar-sized chunks of work, the moving-through-phases metaphor gets in the way again.

Phases are liable to proliferate, until you want more columns than is practical for an actual corkboard. For any given phase, you might want to distinguish between "Ready to be picked up" and "In progress." Even if you're tracking virtually in a project-management tool, having too many phases is still annoying; you spend your time clicking dropdown lists instead of creating software. If you're in this mode, though, one solution for distinguishing between "ready" and "in-progress" is to write your name (or set the "Assigned To" field) on an item when you claim it.

Some items visit a phase more than once—like when a tester discovers a bug and gives the story back to a developer. (See that hand-off? That's the non-Agile-ness rearing its head again.) So when you see an item in the development column, is that its first trip through, meaning a lot of work remains, or a subsequent trip and it's nearly finished? You can't tell by looking at the board.

A communicative tracking tool would show you where bottlenecks or wasteful idleness is occurring. Using phases obfuscates this as well, because it implies that your testers aren't even looking at a user story until the coding is complete. (Can you call a piece of coding complete if it hasn't been tested or shown to the product owner? I'd say not. So read "complete" as a different word that represents "passed from the Development phase to the Testing phase.") But testers at the beginning of a sprint are creating test plans and collaborating with developers and product owners on the acceptance criteria; their "Testing" column looks empty, but they are in fact very busy with useful work. Someone outside the team might look at the board, conclude that the testers are idle, and be tempted to distract them with other tasks.

What a list. It's strange to me to write it. At my old job, my team had to have a virtual task list so that we could share it across continents. I was always jealous of the kids who got to have real live note cards on real live corkboards. Oh, how wistful I was, to have such an elegantly simple solution.

But now that I've used a task board, I can see its limitations, and I wonder about alternatives. I still want to cling to the belief that a tangible solution is better than a software tool, but I might have to let that go. Software is much better, for example, at turning points of information into a communicative picture. It is also better at searching, archiving, sharing with out-of-town stakeholders, and scaling.

The right solution will radiate information. It will clearly communicate whether the sprint is on track and likely to conclude successfully. It will alert you to lurking risks, so that the team can react and adapt proactively. It will tell a story about the sprint from which you can learn during your retrospective. These are the requirements by which I'm evaluating tracking techniques. The right method will show the heartbeat of the sprint.

You're too kind. Tip yer waitress.

There's a "Pho King Coming Soon" sign near my house, which means there will soon be another Pho King restaurant. I wonder what their Pho King food will be like. I hope they have good Pho King service, and a nice Pho King ambiance.

Oh, why get excited? It's just Pho King noodles.

Yes, Jon and I can amuse ourselves for miles with this gag.