Marcato

Every new team starting Agile goes through an awkward phase where you are beginning to walk but the steps just are not natural yet.  During the first sprint, you are happy just to see the various Scrum practices put into play, but you also are building the tools and infrastructure as well.  Even if you had the luxury of having an existing Application Lifecycle Management (ALM) tool in place, you are still learning how to use it and to organize your information inside of it.  However, it is a reasonable goal for the team that you would have these mechanics in place by the end of the first two-week sprint.

In our current project, we decided that with the second sprint we would tackle getting enough information into the tool (in this case, Microsoft’s Team Foundation Server or TFS) that we would be able to see an actual burndown chart.  For this to work, you need to get the rigor in place to have the team breakdown stories into tasks (or in TFS, Product Backlog Items into Sprint Backlog Items), give the individual SBIs an estimate of total effort, and also update the time remaining on a regular basis throughout the sprint.

Of course, even if you do these things, you probably won’t get the sprint burndown chart that you see in the books (you know, the one that is a straight line going down and to the right and intersecting the x-axis on exactly the last day of the sprint).  In order for the chart to look like you want, you need to be able to foresee all the work and break it down into tasks on day Zero.  You also need to be able to keep the team focused only on work that related directly to the stories that were purchased, and you need to have all team members execute the work with the productivity they expected.  Gee, is that all…

Instead, what you are likely to see is something like this:

Burn Up!

Why is this happening?  For lots of reasons, and all of them good (in the long run), and the worst thing you can do at this stage is panic.  We did task breakdown and estimation, but not consistently across the team.  A few of the team members knew that their number one priority was going to be working on the build and deploy process, but we were slow to get a story created for that, and since it was really more of a discovery process, it really was more like a research spike that had to get finished before other work could progress in a meaningful way.

As you can see from the picture, we were mid way through the sprint when another round of task breakdown and estimation happened.  First, the sprint backlog improved as we closed out completed tasks, but then it climbed right back up again as we identified and estimated more work.

It’s still early as the sprint is not done for a couple more days, but it will take something of a miracle to get all the work that remains done in those couple of days.  Is this cause for concern?  Sure, but only in that there will be a lot to learn from the sprint and to refine during our next retrospective.  Some of the team members are new to the process and will need to see it in action again to really get it, but with this picture we now have a good example of what NOT to do, and with this kind of visibility, improvement is just around the corner.

Winter Sunset - Coon Rapids, MN

In general, I would say that you should expect it to take 3-4 sprints over 8 weeks of time before you see your velocity stabilize and your sprint burndown charts start to burn down and not up, so if you are still within that window, then gentle course correction should be enough.  However, if it has gone on longer than that, then there is a leadership issue and an intervention is needed to get the team to take this more seriously.  This is the process capability that leads to predictable outcomes, so you have to invest the time to make it work.  Remember – first measure, then improve.