Chapter 10 in Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller, dives into planning.. Sprint planning one of the major events in Scrum. All sprints should start with planning (not planning is one of the silliest, but a common antipattern). Todd and Ryan begin the chapter by reminding the reader of the definition of sprint planning and the output of the event. The outputs of planning are a sprint backlog containing a forecast, the Sprint Goal, and knowledge. I am always amazed by the amount of information and knowledge generated during planning, as the whole team knows what they are going to tackle and how they are going to tackle it. Planning is a TEAM EVENT. The scary part of this chapter is that none of the antipatterns Todd and Ryan identify in this chapter are common.
The first of the anti-patterns is marathon planning events. I remember watching my first sprint planning session at a client in Los Angeles, California. I was auditing a troubled project for the CIO, who was based in New York. The teams on the project had decided to “do” Scrum while the account’s senior leaders were out of the country (this was one example of the strange things going on). The first sprint planning session took three very painful days. The sprint review occurred six days later, and took one full day (there is not a lot of time to finish work if you spend three days out of 10 planning). While lack of coaching and poor training contributed to the grinding planning sessions, the most significant issue was that the backlog was poorly refined. Good refinement shows a high positive correlation to good sprint planning. The pain is avoidable!
One of the anti-patterns I see with great regularity is not using the concept of a sprint goal. Teams don’t use the sprint goal for many reasons ranging from not understanding the idea of a goal, to doing random work. I’ve recently been in a Twitter conversation with Chris Hurney. Chris has been on the SPaMCAST many times and is one of my go-to people I go to for ideas and advice. Both of us agree that the sprint goal is one of the most important parts of Scrum. The goal focuses the team’s effort and it allows a team to actually adopt the principle of maximizing the amount of work not done. Even when done, writing the goal is often done poorly. One of the common mistakes is to adopt a list of backlog items or a to-do list. The goal describes the purpose of the sprint tied to the business value of the problem you are trying to solve. As the team completes work, they can test whether they have met the goal. When the team reaches their goal, they can pivot to another goal rather than gold plating the first one. The concept seems so easy, yet I have discussed sprint goals with many Scrum Masters and team leads over the years who throw up their hands and say “we are just here to do the stories we are asked to do, someone else needs to worry about the big picture.” Often the problem is training and practice in writing sprint goals. Crafting a motivating sprint goal was not easy for me until I practiced and experimented with approaches. Without a goal, teams are faced with the grinding job of completing tickets from a never-ending pile. It can be mind-numbing.
Are you unsure of what a sprint goal is? I recommend reading the ‘Joe Asks’ (sidebar) early in this chapter for a succinct definition. You can also read my blog on the 5 attributes for writing good sprint goals.
One of the takeaway lines in this chapter is on page 128, “remember that the development team owns how to accomplish the work.” This reminder has been on the lips of nearly every creator I have ever known. Whether you are coding a solution, configuring, or assembling a solution, oftentimes someone wants to tell you what they want and how you are to do it. In the long run, not separating the what and how ends up causing teams to not to clean up technical debt that they discover (or create) when solving current problems. Increased technical debt leaves any system less maintainable, more fragile, and if nothing else just plain costlier to work with.
Sprint planning is the beginning of any Scrum cycle. Planning is a team event and done correctly provides the basis for the team to work forward focused on a goal. Like a rowing team, good planning ensures that everyone has a good start at pulling in the right direction.
If you have not bought your copy — what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems
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
