The sprint backlog is the work teams do on a day-to-day basis. A sprint backlog is a tool that the team uses to guide their activities. The backlog is a combination of outputs of other activities such as the sprint goal, accepted product backlog (not the same thing as the sprint backlog), and at least process improvement items and activities, such as sprint planning and day-to-day planning. Quite a mouthful. A less complete but more easily understood description of the sprint backlog is “the things the team needs to do to deliver value.” The sprint backlog gets created over and over during sprint as they discover information and knowledge.
This chapter exposes several common antipatterns. While all the issues are problematic, most are a reflection of a disconnect between Scrum teams and the management hierarchy. Burndown or burnup charts are common tools used to visualize progress. Early in the age of Scrum, the “burn” charts were a silver bullet for transparency. Over time the working to the burndown chart can become as important as delivering on the sprint goal; following the plan represented in the burndown chart supplants the value delivered by the team. Unfortunately, I have observed the outcome of this myopia. When working to the burndown becomes the goal of management, the team will act in an economically rational manner. They will work to the plan and often fail to deliver the committed sprint goal or they will cheat by doing what they need to do and reporting something else. The burndown is only valuable when used to facilitate the micro-planning and coordination that occurs as people work together and adjust to meet the goal. Get a sticky note and write “the sprint goal IS NOT the burndown chart” and stick it where you will see it on a daily basis.
A second topic that is a constant source of annoyance is the lack of transparency tools can create. I agree with the authors that a physical Scrum board is still the gold standard. There are many reasons to have a physical board but the most important is that it allows leadership and the team to see the big picture. Tools make it very difficult to see the whole picture without a 69-inch computer monitor. Also, very few senior leaders have the time and patience to do a deep dive into any of the popular project management tools. The outcome is the need for status reports and meetings. Remember that every minute spent working on status is a minute that is not being spent delivering the ultimate goal of the sprint.
The final item I will highlight in this chapter is who owns updating the sprint backlog (many people use the phrase, “the board” as a verbal shortcut). As a coach and guide, I spend a lot of time watching people. One of the most common indicators that the sprint backlog is a management artifact rather than a team tool is when the Scrum Master or team lead is the person charged with maintaining the plan. A close relative is a backlog that never gets updated (and is rarely looked at). Todd and Ryan point out that this is an outcome of micromanagement. It is also an artifact of 19th and 20th-century manufacturing management that does not recognize that the smartest people in the room are often those doing the work rather than those overseeing the work.
The authors suggest as an exercise; first, the team identifies the workflow needed to deliver the sprint goal. The board should mimic the flow which will allow the team to identify the constraints and bottlenecks. When the terms visibility and transparency generate a process that makes it harder for the TEAM to understand and adapt how they are working to the context they are facing something is wrong.
If you have not bought your copy — what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems
This Week’s Installment
Week 10: Sprint Planning – https://bit.ly/3stWOhx
Previous Installments
Week 1: Re-read Logistics and Front Matter – https://bit.ly/3mgz9P6
Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad – https://bit.ly/37w4Dv9
Week 3: Breaking Bad Scrum with a Value-Driven Approach – http://bit.ly/3stGc9Q
Week 4: The Product Owner – https://bit.ly/3qpKvSn
Week 5: The Product Backlog – http://bit.ly/3cAEk9c
Week 6: The Development Team – http://bit.ly/2OLVAAs
Week 7: Embracing The Scrum Master Role – https://bit.ly/3m0HB5D
Week 8: Management – https://bit.ly/31Kv39l
Week 9: Thinking In Sprints – https://bit.ly/321wXTg
