Let’s start with Sprint planning.
It’s the first event in scrum, the first meeting inside that sprint.
It’s a time to work out what you are going to do, why you are going to do it, and how you are going to do it.
We start with looking at the backlog items and making a decision about what makes sense to include in the upcoming sprint backlog. Which items are the highest value and which of those items are ready for the team to tackle in the sprint.
Which items go well together and make sense to include in that sprint?
The developers are going to work through these items and have conversations with the product owner as well as the development team to make sense of what needs doing and how best to achieve the sprint goals and objectives.
The conversation is going to guide the team to understand what the goal for the particular sprint is and why it’s important that they achieve that goal.
Many people fixate on the backlog items themselves but in scrum, we commit to the sprint goal not the items.
So, the team may decide that these 12 items make the most sense given the priority of the items in the backlog, but what we are going to focus on is delivering that specific sprint goal.
The sprint goal might be really simple.
I once had a team that made ‘get something into production’ their sprint goal. It didn’t matter what it was, it was simply to get something into production.
As they moved through items, they discovered that certain items weren’t ready for completion as yet because they still required permissions, other items were also discarded during the sprint, but at the end of the sprint, they had achieved their goal because they did get one item into production.
Based on that sprint goal, and the achievement of that goal, the sprint was considered a success.
So, the goal becomes incredibly important because that, in essence, is what the team are committing to achieving within the sprint.
Some of the backlog items you select may need to be discarded due to dependencies elsewhere or lack of information, skills, etc. and as such, you want the team to focus on achieving the sprint goal rather than becoming too fixated on ensuring that each item in the sprint backlog is completed.
The sprint goal creates that point of cohesion for the team to truly form around.
So, that covers what we’re going to do and why we’re going to do it, next part is the ‘how’.
At this point, the team have decided what they are going to do, and that is still up for negotiation throughout the sprint planning process, now they need to figure out how they are going to do the work that is required.
They may break things down into tasks or they may discuss which options are available to them as well as which options they are going to discard. Based on right now, what is the right thing to do and how is the right way to get it done.
The team will be discussing how best to accomplish a goal or specific objective and they will work through all the options available to them.
In essence, they are asking what the right way to do something is, today.
In doing so, they are going to uncover more assumptions. Potentially, they may even discover that more work is necessary.
It’s great if the product owner stays throughout the duration of the sprint planning for that reason. Work may change. New elements may be discovered. Additional work may be discovered.
The product owner needs to be available to help with decision making around what the most important and valuable work is and why it is necessary to be completed within the specified sprint.
The team may also discover, through conversation and thinking about the problem at hand, that they can’t actually complete that item within the sprint. They will discuss this with the product owner and decide to discard the backlog item from the sprint until such time as the item is ready for a sprint backlog.
In my experience, teams fall into 2 distinct paths when it comes to sprint planning.
The first, most inexperienced teams, will invest roughly 30 minutes on the sprint planning and decide which items need to be included in the sprint backlog. They will identify what needs doing and they will identify why it needs doing but they don’t invest time figuring out how it will be done.
They simply crack on with the sprint and start working on the items in order of priority.
It’s only in the doing phase that they may discover that they don’t know how to complete the item or that there are dependencies which they didn’t consider when including the item in the sprint backlog.
At this stage, everything stops.
The product owner and product stakeholders have an expectation that the items will be delivered within the sprint and yet the team will not be able to deliver those items due to impediments and problems which they failed to identify during the sprint planning period.
This results in a failed sprint.
It also results in frustration and disappointment for the team as well as the stakeholders.
It is super important that the team invest time thinking through the problems at hand and how they will complete the items on the sprint backlog during the planning phase.
These conversations and investigations will empower the team to make better decisions about which items can realistically be completed during the sprint versus which items need additional work, skills development, or resources before they can be included in the sprint.
In my experience, teams that fail to plan through to the end often struggle. Things simply blow up in their face and they invest time and effort putting out fires rather than actively creating products or solving problems.
More experienced teams tend to experience less frustration and impediments because they have invested the time and effort to think through the problems and identify how they are going to address the problems they face during the sprint.
They tend to have a far clearer idea of how to build the product or feature and they have a greater understanding of the potential dependencies and problems that may impact their sprint goal.
They may take on fewer items, but they are doing so with the knowledge that there is a far stronger chance that they will complete every item in the sprint backlog and achieve their sprint goal.
They are confident that they have covered all their bases and are capable of completing all of the items selected for the sprint backlog.
Sometimes teams can invest too much time in sprint planning. They will reach the end of their time box only to discover that there are 3 or 4 items in the sprint backlog that they haven’t invested time in identifying how they are going to successfully complete the items.
They may request more sprint planning time to complete those items and commence with the sprint.
I generally advise against doing this.
Teams often worry that they aren’t bringing enough items into the sprint, but you are far better served taking in less and learning that you are capable of delivering more.
The value of a backlog is that there will always be work that needs doing. The team don’t need to do it all in one go. If they get halfway through the sprint and all the sprint backlog items have been completed, they can always bring more work into the sprint backlog.
Doing this will build confidence in the team and teach them how much they are capable of delivering within the sprint period.
In consultation with the product owner, the team will decide on which additional items are best to bring into the sprint and crack on with those. Doing this consistently will help the team grow and learn how to effectively plan for each sprint based on what they have learned in previous sprints.
Facilitating Sprint Planning
Are they bringing a list of work into the sprint planning session that makes sense?
Are there sufficient items in that backlog that are ready to go? Is there enough items that enable the developers to choose which items are best served during the sprint?
The Scrum Master will also be evaluating whether time and effort is being wasted on items that aren’t ready for the backlog. They will be evaluating whether the team are working through items that don’t make sense to be included in the sprint backlog and guide the product owner to refine those items until they do make sense and are ready for the team to work on.
A scrum master will also be evaluating whether the team successfully articulate what needs doing and why it needs doing. Are they having the kinds of discussion that empower them to understand how they are going to complete the work in the sprint backlog?
As a scrum master, you don’t need to have the same technical proficiency as the developers, but you do need to ensure that the developers are having valuable conversations that empower them to identify what they are going to do, why they are doing it, and how they are going to achieve the goal.
Sprint planning is up to 8 hours for a month-long sprint. You will often hear that 4 hours is recommended for a 2-week sprint.
It is a lot of time, but it is necessary for the team to fully work through each element of the sprint and satisfy themselves that they are capable of delivering on the sprint goal as well as the sprint backlog.
As a scrum master, you are ensuring that people don’t forget the critical elements of planning. In their passionate conversations, you’re making sure that the team stay on point and focus on the most important elements of the planning process.
It is your job to nudge them in the right direction and ensure that the right conversations are happening at the right time in the right way.
Sometimes, those nudges might be super basic. You might be reminding the team that there are holidays coming up or that there are training sessions that have been booked. Sometimes, the team can get so wrapped up in the tasks that they forget these simple elements and how much of an impact they will have on the team’s ability to deliver on a sprint goal.
A scrum master will help the team to determine their capacity. New teams often struggle to accurately determine how much they can do within a sprint period and the scrum master is on hand to make sure that this is a process of continuous learning and adaptation.
A scrum master reminds the team of the reality they face, and which impediments may prevent the team from completing all of the items they have selected for the sprint backlog.
In some cases, the scrum master is the voice of reason that helps the team discard one or two items to ensure that they have a successful sprint and achieve their sprint goal.
Using data may demonstrate that the team successfully completes 30 points per sprint on average and yet this new sprint they may have selected 100 points. The scrum master will challenge that thinking and present data that effectively helps the team make better decisions.
Sometimes, the scrum master may discover through conversations that the team is capable of handling more points in each sprint and make a note of what changes have occurred that empower the team to handle more work in each sprint.
The role of a scrum master is to get the team to reflect on what can and can’t be achieved. They aren’t saying no to the team, they are simply challenging conventional thinking and empowering the team to really think through what can be achieved and how that will be achieved.
A scrum master plays an important role in facilitation. It isn’t simply about ensuring that the right people show up, it’s about guiding their attention throughout the process and making sure that the right elements are being discussed, at the right time, in the right way.
It’s about helping the team walk through a successful planning session and walk away with clarity about what needs doing, why it needs doing, and how they are going to successfully complete the work.
If you like the idea of mentored and coach-driven skills development, visit our Agile Coach Academy.
If you have identified coaching as a valuable skill to develop, visit our on-demand Introduction to Coaching course page.
For more information on John McFadyen, visit https://www.growingscrummasters.com