After writing about sprint backlogs
-- how you can create one and why it should be the big elephant in the room -- I remembered that 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 ever asked yourself how to fit legacy bugs into a sprint without endangering the commitment? If so, then this post might help you.
The Scrum framework has a well-defined rule regarding the injection of "not committed" work: You don't inject.
If you really need to do something not planned, then you abort the sprint and replan. This obviously makes a lot of sense: The team has committed for a certain scope within a fixed period, and if you add stuff but the time is still the same. . . . Well, no can do. Abort and replan a new sprint.
Despite this beautiful simplicity of Scrum, we know that life is sometimes not that easy. 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 without aborting the sprint and replanning everything?
Handling bugs in a sprint
The way I've found to handle these bugs was to create what I call the Buglog.
The first step is that both the team and the PO agree that one team member only (or a pair, if you have lots of bugs and need to keep knowledge in same level) will 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. In fact, 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 eight people and decides to have one person on bug fixing, then the team availability will be seven people. If you base your commitments on your velocity
only, then you should commit to a bit less than your average velocity, because one person will be "out for bug fixing." Consider it as though each day the team had one 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 ones that must 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 and quick to fix, you can list more, but for the sake of simplicity and quick visualization, keep it small -- you can add more at any time!)
Team member assignment to bug fixing
At this point the team has its sprint backlog, with the committed user stories and the buglog with the most important/urgent bugs.
In the same way that the team looks at the sprint backlog and each team member assigns himself to a task (by picking a task that the team has defined as a priority among the current goals), the team also looks at the buglog and checks current priorities. According to those, someone from the team assigns himself to do bug fixing that day.
(In my experience, the self-assignee is normally the person that knows the most about the bug or the area where bug is.)
It is really important to repeat this:
Every day the team looks at the list and agrees on who will do bug fixing. Some days the person from the 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 now have most of the team working in the sprint backlog, and we have this special bug-hunter-of-the-day team member fixing bugs. He or she starts with the one on the top of the list and has as the goal to fix as many possible during that day. (You can even propose a contest for the Mightiest Bug Hunter.)
The day's bug-fixing team member should also be present in the team daily Scrum. First because the next day he or she will be back to sprint backlog tasks, and second because it's important for the rest of the team to know which important bugs are being fixed.
I've always carried on the daily stand-up as usual, with team members talking about their sprint backlog tasks and impediments and together defining what to do next (team daily planning). The team member doing bug fixing would be the first or the last to speak, discussing bugs fixed and any doubts or help needed to tackle the next bug. We would ask this person to be the first or last one to talk because that way we wouldn't break the flow of conversation around the sprint backlog when the other team members start discussing it. But nevertheless, the Buglog is seen as part of the overall team scope, just with the slight difference of being handled by only one person each day.
Deciding bug priorities
As the list gets smaller, with the bugs moving to the Done column, the PO will decide which are the next most important bugs.
On one of the teams I worked with, every morning the PO received a report from an offshore quality team with all the newly 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. If so, then he would reorder the bugs.
Conclusions of my experience
Legacy bugs are fixed.
You can use this Buglog to add small improvements in older stories or deal with technical debt if/when that is your biggest pain point.
POs are happy because they see stories being done and bugs from the past being fixed, all leading to a more stable solution for the customer.
The team is happy because it doesn't feel interrupted from work on user stories, and as a team everyone can still fix those nasty bugs they are worried about.
The ScrumMaster is happy too -- there is less yelling (I'm kidding), less "we need to replan the sprint because if we need to fix all that, we can deliver our US," and a higher feeling of trust between the PO and the team, because 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 trade-off involving the team, the PO, current customers, and future customers.
I hope it helps you as much as it still helps me and my teams.