You are here: Home // Agile, Project Management Practice // Scrum Sprint Burndown Chart

Scrum Sprint Burndown Chart

We use Agile software developments strategies and, for project management, Scrum is our preferred technique. Our development team are based offshore and there are challenges to creating Agile function with a distributed team however it could be completed (and might be enjoyable also!). So I thought I would share a story with you 1 of our real Sprints as told through the Scrum Burndown chart. Why? Well, simply because I think we can understand a fantastic deal from the Burndown chart and every person has its own story to tell. Here’s ours:

To set the scene, my Scrum team met (virtually needless to say) to strategy the next iteration of our work creating a bespoke sales order processing program for a significant UK utilities company. We knew which user stories the client Product Owner wanted in this Sprint and so we sat down, listed the tasks needed to create the user stories and estimated in hours how lengthy every one would take. This initial estimate came out at 90 hours.

Having already been via several Sprints, we had a great idea of the team’s velocity and reported to the Product Owner that this was an excessive amount of to total inside the regular 2 week iteration. Nonetheless, given the significance of this functionality to the client, and to maintain momentum leading up to the Christmas period, it was exceptionally agreed to run this Sprint for longer than typical.

All began nicely and good progress was created, the truth is we had been ahead of schedule. Then, several days in, among the team realised that a further task was needed to total one of the user stories – so this was documented, estimated and added to the Sprint Backlog. This increased the estimated hours remaining by a further 16 hours and so the Burndown chart tracked north.

Inside a couple of days, an additional unexpected incident occurred. The British Government announced a decrease in the VAT rate (sales tax) and, as the method we have built for our client is really a sales order processing method, which includes pricing & invoicing calculations, we knew that this statutory change would need to be tackled as a matter of priority. Now, we’re a small team (what Agile team isn’t) and we quickly realised that all current development function would need to be suspended to make this critical change.

So we parked this Sprint and worked by means of the week and the weekend to successfully deliver the VAT change ready for the implementation date a week after the Government announcement. As a result, our Burndown chart flat-lined for a week. We therefore realised that this would impact on our estimated delivery date and so began to look at a revised completion window for this Sprint.

However, before we could total this, the next hurdle appeared in front of us. The developer who had picked up a new job realised that it was more complex than we had originally estimated; as a result the effort remaining increased by a further 36 hours, leading to another upward spike on our chart and, needless to say, further delay in delivering this Sprint. So, again, based on the team’s velocity, we re-estimated and come out having a revised completion window.

Now, I can already hear some of you Scrum experts out there shouting at me. Surely we should have time-boxed the iteration and not extended it? When we dropped inside the new task we should have possibly looked to the Product Owner to remove something in compensation in order to deliver within the Sprint? And all this is true – in an ideal Scrum world that’s what we would do. But, we know our client properly, we have an excellent relationship with them, and we knew how important it was to them to get this functionality in before the New Year. So I bent the Scrum rules to accommodate their needs. Now, before I’m drummed out of the Scrum gang, we shouldn’t lose sight of the Scrum values:

  • Be willing to commit to a goal.
  • Do your job. Focus all of your efforts and skills on doing the work that you’ve committed to doing.
  • Don’t worry about anything else.
  • Scrum keeps everything about a project visible to everybody.
  • Have the courage to commit, to act, to be open, and to expect respect.

Now, I’ll accept that we bent the Iteration rules a little, but it was for good reasons. We faced some unexpected change during the Sprint. But we had been open and honest with the client and we had been able to use the Sprint Burndown chart to quickly show the Product Owner the impact of change and gain their approval to proceed.

More importantly, we stayed in control and retained order in what could have been chaos.


Leave a Reply

Copyright © 2010-2012 Home of Project Manager. All rights reserved.
Focus on project management. Powered by MyPmHome Team.