After writing about Sprint backlogs – how you can create one and why it should be the big elephant in the room, I remembered we rarely see people talking about the nasty legacy bugs the scrum team gets during the sprint and how to fit them inside the sprint.
First a disclaimer: when I say bugs, I do NOT mean bugs from the User Story (US) currently being implemented by the team. If the bugs you find are related to the US in progress, then these bugs are part of the current work, part of the current sprint scope. So, when I say Bugs in this post I mean bugs that we have from previous User Stories, from Legacy code.. bugs that don’t fit the current Sprint Scope.
Have you asked yourself several times how to fit legacy bugs in a sprint without endangering the commitment? if yes, then this post might help you.
Scrum framework has a very well defined rule regarding injection of “not committed” work: you don’t inject.
If you really need to do something not planned, then you abort the sprint and re-plan. This obviously makes a lot of sense, team has committed for a certain scope withing a fix period, if you add stuff and the time is still the same..well.. no can do. Abort and Re-plan a new Sprint.
Nevertheless this beautiful simplicity of Scrum, we know that life is sometimes not that easy and if a customer is complaining about a bug we should handle it and fast, so how can we do that without endangering the current sprint commitments and at the same time without aborting the sprint and re-plan everything again?
Handling Bugs in a Sprint
The way I found to handle this bugs was to create what I call the BUGLOG.
First step is both team and PO agree that one team member (or a pair if you have lots of bugs and need to keep knowledge in same level) will only be available to fix bugs during the sprint. Nothing else, just bug fixing. By one person, I mean any person, you don’t have to assign one team member in particular, the team members will assign themselves daily according to the bugs in the BUGLog.
As you break the stories into tasks and build your backlog during sprint planning (in order to find out what can you commit to), you will consider team availability equal to Team availability MINUS 1 team member.
Example, if your team has 8 people working, and decides to have 1 person for bug fixing, the team availability will be 7 people.
If you base your commitments on your velocity only, then you should commit to a bit less than your average velocity, because 1 person will be “out for bug fixing” :)… consider it has if each day the team has 1 person off for vacations.
Now that you did your sprint planning and you know which user stories you’ve committed, it’s time to build the BUGLOG:
The BUGLOG is a second board, placed next to the Sprint backlog, having the TOP 10 most important bugs – the one’s that need to be fixed first (I use TOP 10 or 5, but it’s actually up to your team and PO to decide… if they are all minor fast-fixing you can have more, but for the sake of simplicity and quick visualization, keep it small… you can add more at any time!).
Team Members assignment to Bug Fixing
At this moment the team has it’s Sprint Backlog, with the committed Us and it’s BUGLog with the most important/ urgent bugs.
The same way the team looks at the sprint backlog and each team member assigns himself to a task (by picking a task which the team defined as priority in the current goals) the team also looks at BUGLog and checks current priorities. According to those, someone from the team assigns himself to do bug fixing that day.
(From my experience the self- assignee is normally the person that knows more about the bug or the area where bug is).
It is really important to repeat this : Everyday the team looks at the list and agrees on who will do bug fixing. Somedays the person from previous day decides to continue doing bug fixing because it makes sense. But the rule is that we all have our share of bug fixing.
We have now the team working in the Sprint Backlog and this Special Bug-hunter-of-the-day team member fixing bugs. Starting by the one in the top of the list and having as goal to fix as many as he can during that day! (you can even propose a contest ;) for the Mightiest Bug Hunter).
The assigned Bug-fixing team member should also be present in the team daily scrum. First because the next day he will be back to Sprint backlog tasks and second because it’s important for the rest of the team to know which important bugs were fixed.
My experience: I’ve always carried on the Daily stand up as usual, team members talking about their Sprint backlog tasks, impediments and together defining what to do next (team daily planning). The Team member doing bug fix would be the first or the last to speak during daily standup, about bugs fixed and any doubts or help needed to carry on next bug. We would ask this person to be the first or last talking because that way we wouldn’t break the flow of conversation around the sprint backlog when the other team members start speaking. But nevertheless this small thing, the BUGLog is seen as part of the overall team scope, just with the slight difference of being handled only by one person each day.
Deciding Bug Priorities
As the list gets smaller, with the bugs moving to Done column, the PO will decide which are the next most important bugs.
(In one of the teams I worked with, the PO received every morning a report from an offshore quality team with all new found bugs. In this case the PO would, every morning, look at the current list of ‘Not yet being fixed bugs’ and look at the report received from quality, and decide if there was any new bug more important than those already in the BUGLog. I so, then he would re-order the bugs.)
Conclusions of my Experience
This BUGLog actually proved to be a great solution to our needs:
1- Legacy bugs are fixed
2- You can also use this BUGLog to add small improvements in older stories or deal with technical debt if/ when that is your biggest pain point
3- PO’s are happy cause they see stories being done and bugs from the past being fixed, all leading to a more stable solution for our customers
4- Team is happy cause they don’t feel interrupted from their work in US and they can still fix nasty bugs they are worried with
5- Scrum master happy too, less yelling (kidding) ;), less: “we need to replan the sprint cause if we need to fix all that, we can deliver our US” and feeling of more trust between PO and Team, cause this system allows both to do what needs to be done without anyone feeling that unplanned things can’t be handled.
For me this proved to be a win-win situation, a tradeoff between both the Team, Po, current customers and..future customers.
Hope it helps you as much as it still does help me and my teams!
Happy easter :)