What unit to use in burndown?

What unit do you use for plotting your Burndown Chart? Do you use “Remaining Hours” of the tasks? Or perhaps “Story Points” of the stories in the sprint backlog? Or something else?

Up until recently I’ve taught Scrum teams to just sum up the number of remaining hours for all tasks on their Scrum Board, and plot that sum on the burndown chart. That has been my default approach and I haven’t really experimented with it.

Why even bother breaking down a Story into Tasks?
The immediate answer to this question is of course that we do it to be able to sum up estimated Remaining Time. Duh :-). But I think there’s more to it, because a Story is more than just the sum of its Tasks. The real reason, I believe, is to get the team thinking; to get the team to reflect over what challenges the Story hides so that they maintain an as clear picture as possible of where the implementing is heading and how the sprint is progressing. This implies that breakdown of a story shouldn’t be done just once (e.g. at sprint planning). The view of what tasks a story contains changes as the implementation progresses and things are discovered. It’s natural that the contents of the story vary over time. Nothing of what I have written here is controversial. It’s all part of Scrum.

What happens in practice?
Plotting a burndown based on the sum of Remaining Time obviously requires that the team first breaks down the Stories into Tasks. This, in my experience, has always been somewhat of a challenge; for the team to actually end up with useful tasks. A good breakdown of a scope into User Stories is hard enough, and then to also successfully break a Story down into good Tasks … Well, it is hard and it requires lots of practice. I’ve always struggled getting teams to continuously reflect over their breakdown and about how to improve it. But in the end, tasks often seem to end up saying more or less meaningless things like “Implementation”, “Testing” and “Review”. Fail.

Failure in Task breakdown like this effectively prohibits the team from having any use of it. A breakdown like this doesn’t say much about the Story and consequently there is little or no use in continuously reviewing the breakdown to try to learn more about the Story as implementation progresses. The only remaining purpose of the breakdown, then, is to force a daily re-estimation, so that numbers can be summed up and plotted on the chart. The burndown and the estimation of Remaining Time becomes an end in itself.

We started counting "Number of remaining tasks"
My team, being in the situation described above, felt that the daily task re-estimation was (more or less) meaningless, and proposed that they should try and completely skip the estimation all together. If nothing else, it would save them that estimation-time that was borderline waste anyway. But they also realized that the burndown has an important purpose (yesterday’s weather, indicating progress, early indication of problems, etc) so they felt that they still needed burndown. But if they don’t estimate Remaining Time, then what do they plot on the burndown chart? Well, they agreed to try to plot the number of remaining (not done) Tasks. Simple! And not completely new; it’s a fairly common practice, if I’m not mistaken.

Interesting consequences of this change
This change in the process had a very interesting side-effect: all of a sudden the Task breakdown produced a large number of highly meaningful tasks. Instead of just saying “Implementation” the tasks that the team now produce actually describe what needs to be done, in pretty deep detail. The number of tasks produced both at the sprint planning and on the Standups is significantly higher now than before, and they say a lot more about what needs to be done.
It just seem to come more naturally now. The only difference is that we no longer estimate the tasks afterwards. That’s it. I think this is very interesting. It’s like if there was a mental block before, that has now been removed once the team doesnt have to bother estimating the tasks. I don’t know, but whatever the reason, I think it's great. The team is satisfied with the change. I feel that the quality of the task breakdown of the Sprint backlog is much higher now, and consequently the understanding of the team’s progress is much better (both for themselves and for me as a stakeholder). The project is more transparent.

The drawback of this change might be that the burndown probably is a little less accurate, because the size of tasks vary a lot. On the other hand, how accurate was the burndowns before, when we were estimating remaining time almost as an end in itself? Hopefully the accuracy now is not much worse. And if it is, I think it is outweighed by the gain in insight and increased feeling of progress.

Let me know how you work with tasks, and why… As always I’m curious to get some feedback.

Agile projects are never late

In the post I want to talk alittle about "late projects". It is a topic that is somewhat current for me and I have spent some time pondering about this phenomenon :-).

The question I ask is: What does it mean for a project to “be late”?

Well, in my view, in order to “be late” there has to be a target-date or a target-state (e.g. deadline or a certain scope or both) that the project’s current state is compared against, and the result of the comparison is that the state is such that either expected date or expected scope isn’t achievable.

If we can agree that this would be some reasonably valid definition of “being late” then it implies that the following factors are involved in “becoming late”:
• Date
• Scope

When a project “is late” it means that (for whatever reason) what was expected to be ready at a given time, isn’t. Date doesn't match scope - or vice versa.

Now, let’s assume that I fix the date, i.e. I commit to delivering my software on a certain date, but I don’t commit to an exact scope by that date. Instead, I make sure that the scope is allowed to flex so that I can deliver only whatever is ready by the time I reach the date that I have committed to. As you all know by now this is what Agile is all about. It is OK to commit to either date or scope, but never both.

Is it now possible for my Agile project to “be late”?

And I believe the answer is "No". An Agile project can never “be late”, because it is impossible. “Late” is a concept that does not apply to Agile projects. By allowing the scope to flex you effectively remove one of the two required factors for becoming late in the first place. Consequently; if the project is late, then it is not an Agile project.

One could of course argue that “being late” can also be when a stakeholder desires the scope to be in a certain state sooner than it actually is. However, in my book this is called “wishful thinking” on the behalf of the stakeholder, and it has nothing to do with the project “being late”. That needs to be handled by proper management of expectations – which Agile and Scrum projects in particular solve by opening up the project with full transparency to stakeholders (velocity measurements, release plan based on velocity, highly visible burndown charts, deep involvement of customers and other stakeholders, short feedback loops with regular deliveries and demos, etc).

What the stakeholder above has to realize is that the scope will be delivered as fast as reality allows. The state the project will be in on any given date is determined largely by the “context” in which the project is being realized. When I say “context” I mean all those factors that are affecting how fast the realization can happen: the competence of team, the cooperation of team members, the availability and effectiveness of tools used, the ability for the team to focus on the task (i.e. disturbances), the mood & motivation of individual team members, the availability of information, the clarity/understanding of what is requested, and so on.

So, let’s agree to never again claim that an Agile project is “late”.

OK? :-)

Scrum. You're doing it wrong when...

…your sprint is so long that you feel you have to make a time-plan for it.
…your Scrum Master tells people in the team what to do and when.
…the team report their progress to the Scrum Master.
…estimates are not done collectively by the team-members who will be doing the work.
...you hear one team-member say to another; “Sorry, I’m really focusing on my own tasks here in order to finish by the end of the sprint, so you will have to solve your own problem yourself.”.
…all stories in the sprint finish on the last day of the sprint.
…lower-priority stories in the sprint gets done before higher-priority ones.
…the team has as many stories in progress as it has team-members.
…the Scrum Product Owner can’t explain every single story in both the Product Backlog and the Sprint Backlog.
…you still think it’s a good idea to write down all requirements before you start coding.
…you consider customer feedback a risk.
…the team doesn’t know who their Scrum Master is.
…your system testing happens all at once, after a couple of sprints.
…you still think that a detailed Gantt chart is a useful planning tool for the software development tasks.
…your sprints are 6 weeks long.
…the team’s burn-down has been flat-lined for three days and they’re not discussing why.
…you think the customer knows what he wants.
…you think the team knows how to build what the customer says he wants.
…the team doesn’t know how much work is remaining of the sprint.
…you think it’s OK if the team has 45-minute Daily Scrum meetings.
…you come running to the team after a sprint and yell “Hey, we have to release now!” and someone in the team responds “…Oh, but wait, we still haven’t done any system testing… And there’s some more code review to be done too.”.
…the team doesn’t know when and where the sprint demo will be held.
…the team constantly over-commits.
…you think it’s OK that the team has their Daily Scrum meetings every other day instead; “It’s their choice, and meetings take so long, so….”.
…the team is persuaded to add more to the sprint than they really want.
…the team accepts to include stories that have not been estimated.
…you don’t collect feedback from the customer after every sprint.
…the team doesn’t know who their Scrum Product Owner is.
…your team is larger than 8 team members.
…the team doesn’t know what the sprint goal(s) are.
…your Scrum Product Owner misses a sprint demo or a sprint planning every now and then.
…the team decides (or doesn’t follow or care about) the order of the stories in the sprint backlog.
…you think the Scrum Master is sort of like a Project Manager.
… you think Scrum doesn’t require or need planning.
… you think you can’t have a deadline or commit to a scope "because you’re using Scrum".
… you think you don’t need to document "because you're using Scrum".
… you commit both to a certain scope and to a certain date.
...you need to add stuff to the sprint half-way through.
…you think the Scrum Product Owner is sort of like a Project Manager.
…the team doesn’t know their velocity, or the meaning of it.
…the team haven’t met the Scrum Product Owner for a week.
…the contents of a sprint demo comes as a surprise to the Scrum Product Owner.
…the team doesn’t know or understand the overall vision of what they’re working towards.
…you can’t release the software after every sprint.
...Scrum doesn't work.