only count finished tasks

Your team has the ritual that the burndown chart is updated ceremonially at the end of each daily stand-up meeting. In today’s stand-up someone points to a card and says “I’m halfway through doing this one.” So you’re tempted to chart the burn of half that task’s points. Don’t. Get into the habit of scoring successes only for completed tasks.

There’s at least one major reason why reporting partial progress is bad: it’s a lie. Just what is 50% of a programming task anyway? Or 80%? Or 90%? What if an unforeseen difficulty arises while developing the last 10%? In nearly twenty years of leading teams and managing projects I’ve learned to believe only three states for a development task: “not started”, “started” and “done.” Everything else (includng “I’ll be done tomorrow”) is optimistic or dangerous or both. So I only count progress when a task is complete.

Initially this may make your burndown chart look like a staircase. There are days when nothing seems to happen because the curve is flat, and other days when the curve plummets because a whole load of things finished on the same day. A staircase burndown chart implies one of two situations: either your task granularity isn’t yet fine enough, or team members are starting one task before finishing the previous one.

When an iteration consists of large coarse-grained tasks, the team is missing out on at least two vital aspects of agility. Every task completion is an opportunity to learn, reflect, demonstrate and generally get feedback on progress, on the design and on one’s own skills. And every task completion also creates a natural time at which to swap pair partner and swap task – yet more opportunities to build the team and foster learning.

Alternatively each time a team member picks up more than one task simultaneously, he is creating a new risk – the risk that we’ll get to the iteration boundary with one or both tasks begun but not complete. At this point the relationship between the system’s functionality (as a releasable increment) and the iteration boundary (as a timebox) is fuzzy at best. If this happens too many times it can become difficult to report to the Product Owner just what’s in each increment.

The staircase burndown is a sign that something is less agile than it could be. So don’t hide it by counting part-finished tasks.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s