We use Agile software developments methods and, for project management, Scrum is our preferred method. Our development team are based offshore and there are challenges to making Agile work with a distributed team but it can be done (and can be fun also!). So I thought I would share a story with you one of our real Sprints as told through the Scrum Burndown chart. Why? Well, because I think we can learn a great deal from the Burndown chart and everyone has its own story to tell. Here's ours:
To set the scene, my Scrum team met (virtually of course) to plan the next iteration of our work developing a bespoke sales order processing system for a major 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 build the user stories and estimated in hours how long each one would take. This initial estimate came out at 90 hours.
Having already been through a few Sprints, we had a good idea of the team's velocity and reported to the Product Owner that this was too much to complete within the normal 2 week iteration. However, given the importance 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 normal.
All started well and good progress was made, in fact we were ahead of schedule. Then, a few days in, one of the team realised that a further task was needed to complete 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.
Within a couple of days, another unexpected incident occurred. The British Government announced a decrease in the VAT rate (sales tax) and, as the system we have built for our client is a sales order processing system, 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 work would need to be suspended to make this critical change.
So we parked this Sprint and worked through 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 started to look at a revised completion window for this Sprint.
However, before we could complete this, the next hurdle appeared in front of us. The developer who had picked up a new task 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, of course, further delay in delivering this Sprint. So, again, based on the team's velocity, we re-estimated and come out with 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 in 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 well, 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 everyone.
* 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 were open and honest with the client and we were 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.
