A good friend of mine ask how to include bugfixes in the Scrum sprint, Scrum - the way I like to do it. We have also struggled with this at mBricks, the bugfixes always seems to take attention from the planned tasks since their priority is often valued higher. We have had a couple of strategies to avoid this at mBricks.
First we tried to put one person responsible for bugfixing according to their internal priority. This strategy gets the bugs done without interrupting the sprint, but it is not very including for the person that is responsible for bugfixing, and often also discussions with the rest of the team is needed, which in turn results in unwanted interruption of the sprint.
Then we tried a strategy with defining one sprint to be a bugfixing sprint, but we were not fully satisfied with that either. The bugfix sprint came to seldom for high priority bugs and also we lost progress in new development.
Now we are trying a new strategy, which is to include the bugfixes in the sprint. Actually we do not differ between a bug/issue and other development tasks. They are all priorities according to their value for the end users and of course weight against their required effort.
Our Product Management tools
There is a lot of different tools available for product management. The one that we re using now is JIRA, which is a system for issue tracking and release planning. It can be extended by a well of different plugins and addons. There is two important plugins that we use:
1. Subversion for source control reference
2. GreenHopper for scrum planning
It was important for us not to have to many different systems to maintain. Now everything is nicely integrated and build around the JIRA core.
GreenHopper
GreenHopper is a great tool that gives us the possibility to plan the new releases of mBricks divided into several smaller sprint releases. All the tasks are different issues in JIRA and the workflow is mapped to the Scrum process. The only missing functionality that I see is to flag an impediment for our stakeholders.
This is the planning board:
This is the burndown chart:
The issue mapping and workflow definition:
As I started by saying; we now do not handle the bugs any different than the rest of the tasks in the Scrum. They are all the same in our system.
Pål Berg, CTO mBricks
May 7th, 2009 at 11:08 am
Interesting post Pål!
Including bug fixing in the sprints have been a headache for me. How do you handle a high priority bug reported in the middle of your sprint?
May 7th, 2009 at 11:26 am
It is of course up to the scrum team, which is the only one that can bring tasks into the sprint. Therefore high priority bug may be left for next sprint.
May 20th, 2009 at 11:09 pm
The shorter the iteration/sprint the faster you are able to deliver that high priority fix without interupting mid-sprint.
Thanks for an interesting read Pål!