- Do you or your participants dread the Sprint Planning meetings?
- Do the events raise more questions than they answer?
- Do they put a dampener on the mood of the participants?
- Do the stakeholders stay away from them?
Many things can go amiss with Sprint Planning meetings, yet they are a vital part of a Sprint cadence in Scrum. In this episode I'm covering a bunch of things that I/we did in the past that helped to boost the success of our Sprint Planning meetings.
"Hello and welcome.
I wanted to add some additional material about sprint planning meetings.
So if your sprint planning meetings are a little bit flat or they don't quite hit the mark, then this is the video to watch.
Hi, my name is Georg and I have quite a few years of Scrum practice under my belt, got to learn a lot. And in this video, I'm delighted to give you a little bit more information about sprint planning meetings. Now, first, let's start with the purpose.
Why would you even have a sprint planning meeting?
It's an integral part of the Scrum framework, of course, but every single part of the Scrum framework has its purpose, and without that particular part of the Scrum framework, Scrum doesn't really deliver what it's supposed to.
So the purpose of the sprint planning meeting is to plan for the upcoming iteration, the upcoming sprint, and ensure that everybody is aligned on what the goal is, the overarching goal that the team has set out to do. And that the additional information that might have come about since the last refinement session has also been taken into account.
Now, this sounds basic in principle, but it's actually very important because the Scrum team really has to appreciate what the overarching goal is. And that is one of the key things that I have observed teams actually skip in a Scrum practice where the sprint planning meeting does not agree on a goal.
And there is also a mistake that I have also made in my practice, ...
...where the goal of the sprint was not agreed properly, where actually each item that the team has pulled into the sprint from the product backlog into the sprint backlog was considered a goal in its own right. And that is calling for trouble. Why that is so, we're gonna cover a little bit later on.
Now, back to the purpose, the participants of the sprint planning meeting are the whole Scrum team. So product owner, Scrum master, as well as the development team members. And for them, it is important to come out of the sprint planning session with an agreed goal, and with agreed set of product backlog items on the sprint backlog. And really also come out with a strategy of how to start the sprint at least used to be the case that the team planned everything out and broke everything down, but that's not necessarily also required because again, things change as they always do.
Now, from the purpose we're moving on to the audience.
The audience is really only the Scrum team. I have experimented a little bit in the past with certain stakeholders or subject matter experts that might come into the sprint planning session, and that might be useful at times, but shouldn't necessarily be a regular occurrence. We do practice transparency in the sprint planning session, there are certainly no secrets. So in some cases it can be really be helpful to have stakeholders who have a vested interest in the particular sprint goal that is being targeted, present in the sprint planning meeting. That is actually all there is to it when it comes to the audience. We don't necessarily want to bloat it or have it out there.
You can, however, and this leads us on to the next key question that you want to cover when you prepare your sprint planning session is where you have it. Some people might really be interested in what you agree and what comes out of sprint planning meetings.
Stakeholders, for example, are another key audience that don't necessarily need to, or want to participate in the sprint planning session, but are curious as to what the actually final agreed sprint goal is that you have worked out.
So it can certainly be, and that's nowadays even easier, useful to broadcast or record your sprint planning session. So you can do that. Nowadays, many of our sessions are happening online, virtually through video conferencing systems like Zoom or Microsoft Teams or whichever you're currently using. And all of those have some sort of recording feature.
So it can be useful to not necessarily record the whole session and then make that available to your stakeholders, but at the very end, give a quick summary as you've finished in a sprint planning session to recap and restate the sprint goal and restate any considerations that are coming in and the risks that you're tackling or that you're aware of, that you are paying down through the work in this upcoming sprint, and then record it and then make that available to interested audiences that are not required for the entirety of the sprint planning session.
Right, that brings us to the next key area, the timing of your sprint planning session.
Now, of course it is somewhat determined also by the Scrum length that you have chosen, in many cases that is still a two weeks across the industry, across the practicing teams. It can be shorter, it shouldn't really be longer unless there is a very good reason for it, because that just delays the feedback cycle of the sprint. And therefore, as soon as you finish your sprint planning session, that officially starts the next sprint.
Now, you want to bear in mind when a good time of days or when a good day of the week is, there is no requirement for your sprint planning to be on Monday morning. It can be really any time that works for you and all of the Scrum team members. So think about any outside aspects that you want to be aware of, availability of stakeholders for sprint review.
And therefore based on when you have the sprint review, you can think about when you have the sprint planning session also. So the timing of your sprint planning is determined by all of those outside factors, but also bear in mind the time of day and when people are at their most energetic, if you will.
If you do it at the end of the day, when all team members tend to be a little bit exhausted and it's quite difficult to have an engaging sprint planning meeting. So have a conversation with the team members, work out what is a good time of day to start the sprint planning meeting.
Okay, so we've got the why, we've got the purpose. We've got the who, the audience. We've got the location where we have it and what you might want to do with any recordings. And we have got the timing.
Now, what we're coming down to is now the what you're covering in the sprint planning session.
If at the beginning, your are starting to look at your backlog and you're trying to determine what you pull in, then that might be a good indicator that if that's what you start with, that two things are there, either you haven't worked out a sprint goal, or you might have already agreed on a sprint goal, but when you're dissecting and clarifying items in the product backlog in order to consider pulling them into the sprint backlog, that is an indication that you haven't spent enough time in refinement sessions beforehand.
So it's a good idea to start with the sprint goal.
Some key tips for the sprint goal are that you want to align around something that actually, from the product point of view makes a meaningful progress on the roadmap. Some key aspects that you want to focus on. It might be focused around performance improvements, quality improvements. It might be focused on a specific feature that you are introducing or a set of features that you are introducing. All of which help you as a team to get closer to whatever the next big product milestone is.
And it should be determined in a way where you can actually validate that you have met this particular goal. A goal can be described in some things that can be validated, but it can also hint at some things that you would only be able to validate once the user has received what you're currently releasing to them, and therefore would not be able to be validated as you are concluding the sprint.
So just bear that in mind, there are leading indicators that could be in the sprint goal, and you could hint at lagging indicators. However, at the end of the sprint, you want to be able to check whether you have met the sprint goal or not.
So there's usually around leading indicators, have you shipped something?
Have you achieved the performance improvement that you can already demonstrate in the sprint review or not?
If your sprint goal describes a lagging indicator, then you will not know whether you've met your sprint goal until after the sprint has long been concluded. So bear in mind how you formulate the sprint goal. If that is of interest to you, how to do that properly, I can do another talk on this and we can work out some examples, for instance.
Now, once you have agreed your sprint goal, the next thing to look at is the top of the product backlog. Are there any news about any final things that weren't quite ready when you had your last refinement session and those items are now ready and meet the team's expectations as the level of clarity and definition that each product backlog item needs to have in order for it to be accepted into the sprint?
So with an agreed sprint goal, the development team then typically looks at the product backlog, and pools item from the product backlog into the sprint backlog. When that is done appropriately, then you'll have a list that is challenging, but achievable, and also based on the capacity that you have in the given sprint.
So you'll need to work out what the capacity is of every sprint.
So that is done by looking historically at how many items you have actually been able to accomplish over the last few sprints. And the more sprints you have, the more reliable that is. And the more you've improved your refinement practices and your planning experience, the more reliable that number will be. But that's not everything that comes to capacity or someone to bear in mind.
Looking ahead at the sprint, do you have any absences of key members due to holidays or medical reasons or loaning them today to other teams for whatever reason? All of those things might have an impact on capacity. So once you've worked that out and you might actually need to go back to the sprint goal, if there have been any material changes, but commonly the two have been established in tandem or dynamically together.
And with the capacity set, then the team can pull the items from the product backlog into the sprint backlog. When you're there, fantastic high five, that's absolutely phenomenal.
And round of applause to the whole team, well done.
Once you're done with part one of sprint planning, you can enter part two of sprint planning. In part two, the team will, while development team in particular with having the option of pulling in the product owner for a clarification, the development team will then look at the sprint backlog, which is still ordered by value versus investment of effort required. And then think about what does it take to get started at the very least, right?
So when the team comes back the following morning or after the lunch break, or depending on whenever your sprint planning session is, what do they need to do? What does actually the work look like to start with?
The first item in the sprint backlog, the second item, the third item, and so on and so forth. You'll need to work out for you as a team, how many of these items you want to break down in this manner? Is it a valuable activity to do? To do it for all of them, that has rarely been the case with the teams that I got to work with, but I would definitely suggest to start with the first two, three, maybe four items, depending on how much work is involved with your cross functional team.
But do start with some of them 'cause otherwise everyone turns up the following morning and then you'll have your daily Scrum, and there's not much to cover 'cause no one has really had an opportunity to work out to how they wanna get started, right?
So sprint planning part two supports exactly that aspect and helps the team be prepared to have a great start into the sprint and get started there.
Now, I'm just gonna check my list here, see if there has been anything else I wanted to cover, but I think we're making pretty good progress. Yeah, yeah , yeah, very good. Okay, so I think I'm done with the list.
Let me know how this compares to your sprint planning sessions in the comments when you watch this video.
I hope this was quite useful for you as a rundown and you could also create a checklist based off of that. If you have any questions about anything that I've covered, please let me know. Or any queries about any other aspects of the work with your team. Also, let me know, I'm very happy to cover these.
This is episode number one of "Team Genius Life". I'm getting into this. I'm quite enjoying it based on this very first episode. I am aiming to do several of these a week, not necessarily every day, depending on what else I'm doing with clients I'm working with or mentoring sessions that I'm having, but certainly several times a day. So so far so good. Let me know how you're getting on.
And thank you very much for watching.
Hope you're tuning in for a future episode of "Team Genius Live."
If you enjoyed this, please hit the like button if you liked it. Or consider subscribing if you would like to get more of this. I'm Georg Fasching, great to serve you, hope to see you soon. Thank you and goodbye."
== end of transcript ==