Sprint Planning

Let's talk about sprint planning. Now, this is one of our scrum events. Sprint planning typically occurs right at the beginning of the sprint. It's where the team is going to commit to the work they're going to do in the coming sprint. Now, this is time boxed to two to four hours. You don't want to spend much more than that doing planning. Again, we think time is better spent building solutions than it is planning. So this is a two part event. In the first part, we're defining why is the sprint valuable. In the second part, we're defining what can be done in the sprint. So let's look at both of those. Okay? So in this first part, why is the sprint valuable? The product owner will present the vision for the sprint as well as the highest priority items from the product backlog and of course, answer any questions around any of those stories. Now, remember, this is probably not the first time the team has seen these stories. Backlog refinement would be another place that they've probably seen this. The next part, the team then really starts to get into those stories. They start to ask questions and go deeper on the acceptance criteria. Does everybody fully understand, do we have shared understanding on each of the stories? The team then estimates. They begin to use Planning Poker to provide estimates on those stories. And once they have estimated a number of stories until they reach the capacity for that sprint, that's it for planning and we're ready to start sprinting. The outcome of this session is a sprint goal and the sprint backlog. So the sprint goal is usually derived from the product owner's vision. Some people will say, will ask me, like, isn't the vision and the goal the same thing? They might be, but I like to have the product owner share a vision and then the team comes up with a goal. And sometimes they might be a little bit different, but the team commits to that goal. Now, here's another interesting thing I like to tell team members. The teams are committing to the goal, they're not necessarily committing to the stories. Certainly there's commitment there, but we're going to do everything in our power to meet this goal. And may mean that some more stories need to be created as we go. Or we might not do this exact story to meet this goal. What we're trying to do is not be prescriptive in the how we'll do that. We're setting the vision, we're agreeing on a goal, and we think it's these stories. But if something comes up as we progressively elaborate aligned to the sprint goal, so we commit to the goal. What are some tips for better Sprint planning? Let's go ahead and look at a couple of those. The product owner having a very well prioritized backlog. The product owner clearly explains the Sprint vision and provides clarification on user stories. The development team members are reviewing stories identifying tasks. This is a key piece of Sprint planning. They're breaking stories into tasks as needed and then they're committing as a team for the Sprint. Of course our Scrum master is there and that person is ensuring that the Sprint goal is is understood and committed to. They perform any capacity planning like who's going to be out on vacation, do we have any planned holidays and is facilitating and managing that event. So Sprint planning again, one of our Scrum ceremonies right at the beginning of the Sprint. It's where the teams are committing to the work they're going to do in the Sprint.