Archive
Sprint Planning
This post is meant as a few hints and tips for new ScrumMasters at Sprint Planning. None of this is meant as this is how you have to do it, but it could be a starting point from which you can inspect and adapt.
When I started as an Agile Coach back in 2007, many teams were struggling with Sprint Planning because they were uncomfortable with uncertainty, or the Product Backlog didn’t exist or was in poor shape. Either of these may result in very long Sprint Planning sessions. Interestingly I am seeing a lot of very short Sprint Planning meetings these days, where 30 minutes is taken to select items for the Sprint, with the team hardly saying anything, sometimes only 1 person is speaking. This is very efficient, but kind of misses the point of Sprint Planning.
Objective
- Agree WHAT we are committing to as a team
- Plan HOW we are going to meet this commitment
With modern implementations of Scrum, with a well refined Product Backlog (which the team have been involved in refining), that first part might be quite fast. The second part is what I now see some teams skipping, there is no conversation about how they are going to do the work. Often this is a symptom of them not really being a team. So to a few tips for new ScrumMasters:
Have a Goal 
Many teams struggle here because the top of the Product Backlog is an unrelated collection of items. Sometimes this is done to make sure the whole team is busy in the sprint based on their specialisms. If you do this you will never have a real team, and that maybe ok. Scrum however is a team game, in the pursuit of a cohesive goal, that represents the value we are going to deliver together. Therefore the first thing you do in planning is decide what you want to achieve in the next Sprint and then select the work that you will need to do. This is the WHAT part of Sprint planning. Don’t talk about How until everyone is clear about What. The goal creates clarity and a sense of purpose.
Get Commitment
Get commitment of the team to the Sprint Goal. Maybe commitment is a dirty word these days, some people prefer forecast. However real teams are not afraid of making commitments to each other, not to managers, to each other. Scrum works when the team decided what they can achieve and hold each other accountable for delivering it. Therefore they must believe their goal is achievable. Involve the team in the creation of the goal, that way they have even more skin in the game.
It’s a workshop 
It’s a workshop not a ceremony or a meeting. Most of Sprint Planning is going to be a technical workshop about how they are going to achieve their Sprint Goal. If it helps call it a technical workshop, maybe the team knows what that is. There is nothing worse than everybody siting round a boardroom style table, calling the same tasks out for each Backlog item. I suppose doing the same thing on different sides of the world is slightly worse. The team will not be engaged. As a ScrumMaster ask the team how they are going to achieve their goal and get out of the way.
Be Prepared
Be prepared as a ScrumMaster, but don’t get rigid. An Agenda can be useful to you and the team, but you will deviate and thats ok, so long as it helps the team.
Don’t touch the pen
As a facilitator, don’t be at the front of the workshop capturing everything on index cards and sticks (or in your tracking system). Sprint Planning is not where you need to put in your star performance at the centre of the stage. Think of yourself facilitating at the back of the room, observing what is happening, when the team get stuck that is when you step in with an observation or question to move the team forward. One rule I have is to never touch the pen, unless it is to hand one to a team member. In this way the team own it.
Bringing Joy to the World of Work
In 2008 I was inspired by Richard Sheridan of Menlo Innovations, and their human focused approach to work. Following his key note at the Berlin Scrum Gathering I think a good focus for everything I do this year would be to bring Joy to the world as I interact with it.
Potential Areas of Interest for the Year
Following a bit of brainstorming with Helen Meek around potential sessions for conferences, we came up with six possible topics, but actually they are also areas of focus for reading, research and writing.
- Risk
- Release Forecasting
- Motivation
- Coaching
- Transformation
- ScrumMastering
Risk
I spoke about using Agile approaches to reduce Risk in 2008 at the Munich Scrum Gathering. Actually I still don’t think we focus on Risk enough, or we focus on the wrong risks. Risk should be part of the value proposition, risk is uncertainty and when we think about Value, yes we should think about customer value, but also validated learning/reducing a risk; maybe so that we don’t build something, this is also valuable. The Risk I see turn into an issue a lot is inherent schedule flaw, where others make commitments on behalf of the team, often based on making the sale rather than on any real notion of how difficult it is to deliver. As yesterday’s issues are likely risks for your next endeavor, lets learn and surly life will be more joyful.
Release Forecasting
Not always necessary, but it can be an effective tool to build trust with your customer(s). So simple, yet it takes discipline to do well. Having a backlog refined appropriately, taking into account that your backlog will probably grow, making promises based on a too optimistic planning velocity. It’s about openness and honesty so that better decisions can be made as early as possible. Which is surly a more joyful relationship than one based on smoke and mirrors and bad news at the end.
Motivation
It still surprises me how often managers do things that de-motivate the team, and either they are unaware of it or they don’t care. It is hard to motivate people, but really easy to demotivate them. People generally join a company motivated, but get worn down by things that are getting in the way of them doing a good job, they enjoy the work, if only they could just do it.
Coaching
Coaching as a discipline is an important skill that needs to exist in managers and teams alike in order promote the collaborative culture, where an Agile approach truly thrives. It is that collaborative culture where I see joy at work. This area is also about me improving as a coach.
Transformation
Many of us will have been involved in both successful and unsuccessful transitions (please provide your own definition of successful). When it is successful I have seen that joy. What have we learned from the failures? What was right about the success? What can we do to have more joy and less bahhhh.
ScrumMastering
The ScrumMaster is a change agent, seeing problems and helping the organization improve for the better, this role should help bring Joy to people by improving their ability to do a good job and have great relationships at work. However often the role is another word for Project Manager, or the technical lead is given extra responsibilities. There are also lots of CSM’s but very few experienced and skilled ScrumMasters.
Six area’s are too many, which area could do with the most work, what would bring you the most Joy?
I will at least commit to writing a blog on each area this year
Wishing you Joy for the upcoming Year
Exploring Agility 