EN 
JA 
IT 
ES 
The Planning Petrification
Are the outcomes of your Sprint Planning pre-determined? Does the meeting feel formulaic? Or even just downright dull? If so, your team have reached what I call the ‘Planning Petrification’. The meeting has reached a point where the flexibility and creativity offered through it has been diminished. It is petrified. It may have even reached the point of negatively impacting the team…but all is not lost! If forming the Sprint Backlog has become a setting for your team to ‘sign off’ on a rigid set of requirements, then I doubt they are moving towards becoming a self-organising team. As soon as they stopped considering the Sprint Backlog as a cohesive unit of work, then resulting increment itself will likely be perceived as ‘bitty’ – lacking value. There is beauty to be seen at the Sprint Planning meeting, you just need to know how reveal it.
Fundamentally, the purpose of Sprint Planning is to produce two things. Firstly, a Sprint Goal – the unified purpose of the entire increment. It is the goal post that the team should be moving towards. It should be measurable, achievable, fixed, and mostly importantly, allow for creativity in how it is achieved. Secondly, the Sprint Backlog itself – the likely work required to achieve the goal. Notice that I used the word ‘likely’ – a common misunderstanding in Scrum is that the team are committing to get the Sprint Backlog ‘done’. Actually, they commit to achieving the Sprint Goal. This is an important distinction – the team can adapt their approach based on their inspection of progress (does ‘Responding to change over following a plan’ ring any bells?).
Here is a technique I propose you try. It works to build the self-organisation, creativity and focus on the collective purpose. Importantly, it requires trust.
Let’s assume all of the Scrum Team are in attendance and you have a nicely ordered Product Backlog that the team have refined over time. The Product Owner knows what she wants to achieve.
Step 1: Throw the Product Backlog away (metaphorically). Inform the team that you aren’t going to use the Product Backlog to drive the Planning meeting.
Step 2: Ask the Product Owner to clearly define the value they want from the next Sprint (specifically not referring to tickets).
Step 3: The Development Team, in collaboration with the Product Owner, define tickets and acceptance criteria for the initial work towards the Sprint Goal. They still aren’t looking at the Product Backlog.
What does this approach achieve? You are removing the crutch of the Product Backlog. They are viewing the planned work as a formed increment rather than a collection of individual tickets. They are collaborating and not signing-off. They are empowered to be creative and get engaged. In short, they buy-in to the value of the Sprint Goal. Remember though, always re-visit the Product Backlog at the end of the session to review your approach – don’t forget that it is still the primary artifact driving the event.
For me, even though the Sprint Review is where overall progress is measured, it is the Planning meeting that I love. Why? Because it’s the point that I get to see how enthusiastic my team are for the upcoming challenge. After all, if they’ve not got the fire in their belly at the starting line, how do you think they’ll feel at the finish line when they didn’t even want to be in the race?