Motley: Bug fix sprints are a Scrum anti-pattern. Quality should be kept high so as not to have to focus on bug fixing.
Maven: A clear meaning of done for sprint tasks is important, but even if you follow this best practice, there will always be integration issues, bugs, and changes required late in a cycle. A sprint focused on these tasks is reasonable.
[Context: Motley and his team of merry developers have been fixing bugs for the past week, and Maven has noticed something odd]
Maven: Morning, Mot. How are things going?
Motley: Not too bad, although I'm a bit late getting in this morning. It's tough to get out of bed when all you have to look forward to is fixing bugs for the next couple of weeks. The bug database is the team's to-do list for the next little while.
Maven: Yeah, this is a part of the development cycle that is rarely a developer's favorite. Is morale still high in the daily Scrum meeting?
Motley: Daily Scrum? Why bother? We are done with Scrum now that we are integrating and bug fixing. Besides, bug fix sprints are a Scrum anti-pattern. Didn't you tell me the other day that Scrum only works for new feature development?
Maven: Um, you must have heard that statement from someone else, or misunderstood something I said. I would partially agree with your statement that bug fix sprints are a Scrum anti-pattern. In fact, most of the Scrum/agile purists would likely say that you are absolutely right. However, past experience and the reality of software development have made me realize that bug fix sprints can be a necessity in large organizations practicing agile development.
Maven: One of the most important concepts of Scrum, and where many teams fail, is having an explicit meaning of done for each and every task on the sprint backlog. For example, a typical coding task may involve the following in its "done" definition:
- Design document reviewed (if necessary)
- Feature fully implemented (including error handling, performance, reliability, security, maintainability and other quality concerns)
- Buddy build complete
- Buddy test complete
- Unit tests written
- Code coverage from unit tests > 80%
- Static analysis run
- Code reviewed by at least one peer
- Code checked-in to the source tree
Motley: That's getting pretty detailed isn't it? What's the point?
Maven: The point is that we all have a common understanding for what it means to complete a specific coding task, and understand what "shippable quality" means. If you do not explicitly define the task, some tasks may get missed costing you valuable time and effort later in the cycle when change is more difficult. With agile, we want to produce high quality deliverables very early and not rely on a long "stabilization" phase at the end. If we do everything we can to prevent bugs up front, we'll actually save time in the long run and theoretically ship sooner. Having defined meanings of "done" for all our tasks is a big key.
Motley: Which reinforces my point that a bug fix sprint is an anti-pattern. Jeez, Mave - did you not have your morning jolt of caffeine?
Maven: If everything goes according to plan and you integrate components as you go, then yes, longer bug fix periods are somewhat of an anti-pattern. But let's be realistic. There is some measure of integration and late discovery of unknowns in any large software project. For a small project of a few thousand lines of code, you may be able to avoid a bug fix stage like this. However, take James' experience in working for a previous company. One thing his team was responsible for was porting a large code base from one platform to another. The team added unit tests where possible but much of the code was inherited legacy code that did not come with tests. The test team worked closely with the development team to find as many problems as possible up front, but when you have tens of thousands of lines of code running on a platform that is changing underneath you, you must expect to find bugs later.
Motley: Not to mention when people in the organization start hammering on your code as real users would. I think James called that "dogfooding" when I talked to him, as in eating your own dogfood. That does not sound very appetizing.
Maven: Correct. You cannot possibly predict all the issues that will arise and fix them proactively. As a result, his team undertook what they called a "quality sprint", which focused on fixing bugs. They took an agile approach and refused to develop new features until the product was at shippable quality, and they hit ZBB.
Motley: What the heck is a "ZBB"?
Maven: "Zero Bug Bounce". It's a moment in time where you have no bugs that are older than, say, three days and there are no ship stoppers. At this point, the team can make a call that quality is high and new features can be developed.
Motley: You called it a "quality sprint". You could also call it an "integration sprint" depending on what your goals are. In fact, that might be a better name for what we are doing now.
Maven: Agreed. The term I don't like ,however, is "stabilization sprint". To me, this implies that the code you wrote was crap to begin with. In reality, there may be things beyond your control that crop up upon integration even though you focused on quality, so I prefer to give it a more positive spin. "Stabilization" also typically implies a huge focus on testing. Testing is part of what happens here, but testing is also happens in every sprint.
Motley: Game it if you want. If it looks like a duck, and quacks like a duck, well, you know. You still have not answered the question as to why I would want to practice Scrum when I am fixing bugs!
Maven: You don't necessarily have to practice Scrum while bug fixing, but you may find it valuable. When your team needs to fit within a larger ship cycle on a big team, you may not have full control over how to structure your bug database. In addition, your team may live within the confines of a waterfall-oriented organization, but you can be agile as a feature team by practicing Scrum and transferring prioritization of fixes to the sprint backlog. The team does the usual sprint planning figuring out which bugs are most important to fix. The sprint backlog is then a prioritized queue of bugs, and devs grab bugs from the queue as soon as they are done fixing their current bug and validating with test.
Motley: Is it really worth the overhead though? I already have my list of things to do in the bug database. Why duplicate it?
Maven: I generally don't consider Scrum as "overhead" - it's a very lightweight process, although I would agree that with any process you arguably get some level of overhead. You could fairly easily write a tool that automatically populated the sprint backlog with the top bugs from the bug database. Note, however, that you also gain the following benefits by practicing Scrum while fixing bugs:
- The daily meetings ensure improved communication and collaboration
- Data gathered is useful for future planning sessions
- Frequent retrospectives allow the team to constantly improve
- The team can adjust priorities during the sprint
- The team need not rely on a rigid bug database schema, and can use the sprint backlog to customize information about the bugs
- The team remains focused, and has a Scrum Master to help
Motley: Fine, fine, fine. We'll try it your way for a sprint and see if it pays off. I did kind of lose track of what Marvin was doing with his bugs and the daily meeting should help.
Note: I'd love to hear some better suggestions on how to deal with the problems discussed in this story. Arguments based on reality (vs. theory) are much appreciated in comments!
Maven's Pointer: Here's another argument for tracking time spent on tasks in a sprint: over several short quality-oriented sprints you can gather data on the amount of time it takes to fix each bug. By mining that data, you can compute an average length of time per bug, which helps you with effort estimates for capacity planning on future bug fixes. Our team, for example, knows that it takes just under 5.4 hours of effort to fix an average bug. We can then estimate how many we can fix during any given sprint, and set expectations accordingly.
- Scaling Testing in Scrum, by Bob Galen, http://www.agile2007.org/downloads/handouts/Galen_532.pdf