Sprint Backlog Antipatterns

Understanding how to create and maintain an effective Sprint Backlog is important since it guides the work the Developers undertake during the Sprint. However, we often see Scrum Teams fall into unfortunate antipatterns. It is important for teams not to fall into these traps. The following are common antipatterns which serve as examples of what NOT to do.

Antipatterns around the Sprint Goal

• No Sprint Goal 
  Why is this an antipattern to avoid? The Sprint Goal is an important aspect of Scrum. It should not be omitted.
   
• The Sprint Goal is simply a description of the selected PBIs -  Some teams select the PBIs they plan to work on and then attempt to craft a Sprint Goal that ties them all together, even if there really is no common thread. 
  Why is this an antipattern to avoid? Creating the Sprint Goal this way minimizes the value and importance of the Sprint Goal.The Sprint Goal is not a summary or label for the PBIs selected. Instead, the PBIs selected should support the Sprint Goal. A Sprint Goal is meant to be an overarching objective that creates cohesion for the work in the Sprint. 
   
• The Sprint Goal changes during the Sprint 
  Why is this an antipattern to avoid? Developers adapt or change the way they attain the goal, but the Sprint Goal must remain the same throughout the Sprint.

Antipatterns around the PBIs and work selected

• Sprint Backlog isn’t updated as the Sprint progresses - This antipattern arises when teams select a set of PBIs during Sprint Planning and don’t modify them once the Sprint begins. These teams either don’t adapt the list of PBIs (by adding or removing PBIs) or don’t adapt the content of the PBI once it’s put on the Sprint Backlog.
  Why is this an antipattern to avoid? The Sprint Backlog should be a real-time reflection of the progress toward the Sprint Goal and the PBIs on the Sprint Backlog should evolve as the team learns more about how to satisfy the Sprint Goal
   
• Sprint Backlog is only updated during the Daily Scrum 
  Why is this an antipattern to avoid? The Sprint Backlog is updated as a result of the conversations during the Daily Scrum. However Developers should also update the backlog to reflect the work in progress as they are doing the work.
   
• The Sprint Backlog never includes an improvement item 
  Why is this an antipattern to avoid? During the Retrospective, teams should identify a few changes in the way they do their work that will improve their effectiveness. These should be added to the Sprint Backlog when practical.
   
• Stakeholders adding new PBIs to the Sprint Backlog 
  Why is this an antipattern to avoid? The Sprint Backlog should be visible to the stakeholders, however they should not have the latitude to modify it. Should emergencies arise, the stakeholders should address them with the Product Owner who will make the judgment about how to handle the issue.
   
• Sprint Backlog is only updated by the Scrum Master or Product Owner 
  Why is this an antipattern to avoid? The Sprint Backlog is managed by the Developers. The Developers may ask the Scrum Master or Product Owner to assist in Sprint Backlog management if it helps the Developers be more effective.
   
• There is no ability to determine how much work remains 
  Why is this an antipattern to avoid? The Sprint Backlog should reflect the current state of all the work for the Sprint. It should indicate the work completed, the work underway and the work that remains.
   
• Laser-like focus on moving PBIs on the Sprint Backlog rather than holding conversations about the work 
  Why is this an antipattern to avoid? The Sprint Backlog is an artifact that helps the Developers guide their work. Moving PBIs on the Sprint Backlog should be a result of doing the work, not the focus of the Sprint.

Antipatterns around Sprint Backlog visualization

• Sprint Backlog isn’t public
  Why is this an antipattern to avoid? The backlog should be visible by the entire team and stakeholders.
   
• Having the Sprint Backlog obscured in a tool 
  Why is this an antipattern to avoid? Poorly configured tools sometimes create process overhead that make it more difficult to easily understand the Sprint Backlog. Tools for managing the backlog should support its transparency, not hinder it.

Team and organizational dysfunctions

• Commitment is to PBIs planned and not the Sprint Goal 
  Why is this an antipattern to avoid? The purpose of the Sprint is to achieve the Sprint Goal. The PBIs selected are a hypothesis of the work needed to achieve that goal.
   
• Management owns the Sprint Backlog rather than the Developers owning it
  Why is this an antipattern to avoid? This antipattern often includes other dysfunctions such as:
  • Micromanagement of the team, rather than Scrum Team self-management
  • Sprint Backlog doesn’t reflect actual progress or impediments. A lack of trust between management and the Developers can create an atmosphere where a more optimistic view of the work is presented instead of the truth. Instead, the Sprint Backlog should be an accurate reflection of the success and challenges that the Developers face during the Sprint. 
  • Pressure to focus on completing the PBIs, rather than focusing on attaining the Sprint Goal
  • Focus on Sprint Metrics such as output and velocity, rather than a focus on customer outcomes
     
• Only the work of Developers in the Sprint Backlog 
  Why is this an antipattern to avoid? Often, Product Owner and Scrum Master have work that must be done during the Sprint. Their work should also be reflected on the Sprint Backlog.