We use agile software development methods and for project management, Scrum is our preferred method. Our development team is based abroad and there are challenges to making Agile work with a distributed team, but it can be done (and can be fun too!). So I thought I’d share with you a story from one of our actual Sprints told through the Scrum Burndown chart. Why? Well, because I think we can learn a lot from the Burndown chart and each one has its own story to tell. Here is the bear:
To set the stage, my Scrum team got together (virtually, of course) to plan the next iteration of our work, developing a bespoke sales order processing system for a major UK utility company. We knew what user stories the customer’s Product Owner wanted in this Sprint, so we sat down, made a list of 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 speed of the team 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 customer, and in order to maintain the momentum leading up to the Christmas period, it was exceptionally agreed to run this Sprint longer than normal.
Everything started well and good progress was made, in fact we were going ahead of schedule. Then a few days later, one of the team members realized that an additional task was needed to complete one of the user stories, so it was documented, estimated, and added to the Sprint Backlog. This increased the estimated remaining hours by another 16 hours and thus the Burndown chart continued north.
Within a couple of days, another unexpected incident occurred. The UK government announced a reduction in the VAT (sales tax) rate and as the system we have set up for our client is a sales order processing system, including invoicing and pricing calculations, we knew it would be necessary to address this legal change. as a matter of priority. We are now a small team (which is not an Agile team) and we quickly realized that all current development work would have to be put on hold to make this critical change.
So we parked this Sprint and worked through the week and weekend to successfully deliver the VAT change ready for implementation date one week after the Government announcement. As a result, our Burndown chart was stable for a week. Therefore, we realized that this would affect our estimated delivery date and therefore we started looking for a revised completion window for this Sprint.
However, before we could complete this, the next obstacle appeared in front of us. The developer who had chosen a new task realized that it was more complex than we had originally estimated; as a result, the remaining effort increased by another 36 hours, causing another upward spike in our graph and, of course, a further delay in the delivery of this Sprint. So again, based on team speed, we re-estimated and got a revised completion window.
Now, I can already hear some of you Scrum masters yelling at me. Surely we should have timed the iteration and not extended it? When we introduced the new task, could we have 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 is what we would do. But we know our client well, we have a great relationship with them, and we knew how important it was for them to get this functionality before the New Year. So I bent the Scrum rules to accommodate their needs. Now, before I get kicked out of the Scrum gang, let’s not lose sight of the Scrum values:
* Be willing to commit to a goal.
* Do your work. Focus all your efforts and skills on doing the work you have committed to doing.
* Don’t worry about anything else.
* Scrum keeps everything about a project visible to everyone.
* Have the courage to commit, act, be open and expect respect.
Now, I’ll agree that we bent the iteration rules a bit, but it was for good reason. We faced an unexpected change during the Sprint. But we were open and honest with the customer and were able to use the Sprint Burndown chart to quickly show the Product Owner the impact of the change and get approval from them to proceed.
More importantly, we kept control and kept order in what could have been chaos.