Matt Anthes-Washburn
writes on September 10, 2015
The “Smells” of Scrum
Do you practice agile software development? Have you or your team ever had the feeling that something is just a little off? There may be clutter in your backlog or the feeling that you aren’t being as effective as you might be. This feeling is a little like when you open the fridge and notice that something smells funny. This helpful (if unpleasant) analogy describes an indicator that may tell you when something in your practice isn’t quite right. It is a commonly-used analogy among those using Scrum for agile software development, where these indicators are called Scrum “smells.” Below are a few of the “smells” your team might encounter and some tips for what you might do about them.
The Smell of Bugs
I can remember one stretch of time when our team seemed to have a lot of bugs cluttering our backlog. The bugs were related to work that we had accepted as “pretty much done,” even though we knew there were a few outstanding issues we would have to return to and address later. Of course, a few surprises will always come up when your code meets real-world usage, but sometimes a team finds they are calling a story, “done,” in the interest of moving on, even when a few issues remain. Those decisions can have cumulative effects on the product backlog.
How did our team address this? In our sprint retrospective, we resolved to make a few changes to our practice. We agreed to be more careful when we review the user story and its acceptance criteria during backlog refinement. We reminded ourselves of a few helpful questions: Can we anticipate problems that might come up along the way? How will we test our acceptance criteria? Since our team included a QA engineer, we asked for her input. With years of experience of writing test cases, this team member was a valuable voice during the crafting of acceptance criteria.
The Scent of Technical Debt
Your product backlog may include technical debt, or backlog items that have technical value but no direct user-facing value. If there seems to be a lot of technical debt accumulating in your backlog, it may be a sign that your team needs to think more about the practices included in its definition of “done.” Code review is an example of a practice that helps with code quality up front, reducing technical debt in the long run. Before a story is done, team members meet to review code and to critique it. This is a good early opportunity to reveal issues that might make the code more difficult to maintain in the long run.
As your team becomes more effective at using acceptance criteria and the definition of “done” to fend off bugs and technical debt, you may wonder what to do with the cruft in your product backlog. If your team agrees to set a little bit of each sprint aside for bugs and technical debt (say, 10%), you can begin to address those items in your backlog without sacrificing work that brings new value to the user.
The Stench of Churn
Churn is a term for changing requirements or expectations. These kinds of changes along the way can cost the team time and cause frustration for everyone. In the context of a user story, churn and scope creep are the direct result of poorly-formed acceptance criteria. Teams can learn to be proactive about these risks by challenging the acceptance criteria during backlog refinement. With a well-crafted user story and acceptance criteria, the team has a reference to go back to during the sprint when they sense churn. The user story and acceptance criteria serve as the source of truth for “What exactly are we building, anyway,” and “Why?”
The Odor of Scope Creep
At one time or another, we have all experienced the evils of scope creep. Scope creep is when a task starts out small and then, often unintentionally, the scope of the project is allowed to grow larger and larger until the effort required is much larger than the original estimate. Scope creep doesn’t just happen in software development; I recently set out to fix a dripping shower faucet and wound up opening the wall and having a professional replace all the plumbing above the floor. That project took a lot more time and resources than I’d planned!
Scope creep for a user story is best handled in a proactive manner, much in the manner we attempt to avoid churn. By applying a critical eye to the user story and acceptance criteria early, and by using them as a reference during the sprint, a team can reduce the effects of scope creep. When a story encompasses a great deal of uncertainty or has dependencies on work or conditions outside the team, it is often helpful to break off smaller pieces of the story and make generous estimates of the effort so that the user story can be brought into a sprint without bringing undue risk of scope creep.
Surprises are unavoidable, and some stories or backlog items take more effort to complete than we expect. When it becomes clear the scope of a story is significantly larger than expected, someone on the team should “blow the whistle,” and call team members’ attention to it. The Scrum Master should facilitate a conversation with everyone on the team, including the Product
Owner. The sprint backlog may need to be reevaluated, and the Product Owner can help with priorities. If one backlog item will take twice as much effort as originally estimated, it is often best to recognize this early and either bump it or another backlog item out of the sprint in order to maintain sprint integrity and to yield “potentially shippable product.”
The Stink of Unfinished Business
Another common “smell” of Scrum is when it seems like the team never quite finishes all the work they committed to in a sprint. I imagine this happens to most teams from time to time; that’s certainly true of the teams I’ve been on. When a team recognizes this “smell,” it’s good to acknowledge it during the sprint retrospective and work together on measures that can improve sprint commitments. It might be a matter of more thoroughly refining stories ahead of time, and perhaps dedicating more team time to backlog refinement. Another approach may be adding some rigor to the check for “doneness,” a topic I covered in a previous post. Finally, it may be up to the team, with encouragement from the scrum master, to be more conservative in their commitments during sprint planning. When the team has had a few successful sprints, with all the work complete, they can start to get a better sense of their velocity and push the limits a little, but just enough.
The Gift of Smell
Finally, at the risk of wearing the analogy out, trust your sense of smell. You and your team will develop this gift over time; it’s important to use that awareness in your favor. The sprint retrospective is a good opportunity for a “sniff check.” The facilitator should periodically ask the team if they recognize any smells. Together, the team can identify steps they can take to address the smell. By devoting some attention, your team should be able to tidy up your backlog a get rid of those nasty “smells.”
To learn more about Scrum, check out How to Get Started with Scrum or the Scrum Basics course.
