Claim Your
Product Coins
My first sprint planning meeting was very challenging and overwhelming. I had participated in a couple of sprint plannings as an observer before I conducted one with my own team. Being the Product Manager for my own team was very different from just being an observer. There were multiple questions from the Engineers that I wasn’t able to answer. From technical details to priorities and launching features.
The result: They pulled way fewer stories than I’d expected.
I was frustrated and mad about the outcome and I wasn’t able to identify why things went the way they did. If you’ve observed or experienced something similar, this article might be helpful. I’ve created a list of the top 12 mistakes to avoid during your (first) scrum sprint planning.
On top of that, I've created a sprint planning checklist that you can get for free.
It’s happened to me a couple of times and I still see this regularly as a consultant:
There are many reasons why teams get themselves in this situation. Even if the Product Manager “owns” the backlog, it’s the team’s responsibility to make sure it’s prepared for the sprint planning. The best way to ensure a prepared backlog for sprint planning is to regularly groom/refine the backlog together as a team.
There are different ways scrum teams execute their sprint planning. I’m a big fan of preparing a clean backlog during the grooming session and sharing the prioritized sprint backlog with the team 24 hours in advance. This has helped me and my teams to save time during sprint planning meetings and meant we had to have fewer discussions on individual tickets.
Backlog grooming is a great tool when it comes to preparing for upcoming projects. As a Product Manager, it’s very important to clearly derive the priorities from the product strategy and roadmap. There are many ways and techniques to define priorities. The Eisenhower Matrix is one of them. There were many times when I caught myself believing that “everything” is important. That’s true and false at the same time. What still helps me these days is asking this one question:
“If there’s only one thing that can be finished in a sprint, what would it be?”
From there on you can go further. If you’ve got more than 3 goals I personally believe it’s too much.
Note: That depends on your team size and performance.
I don’t believe everything needs to have a process, but some structures can be very helpful. A clear agenda helped my teams and me as a Product Manager to remind ourselves to cover all relevant sprint planning topics. Below you’ll find an example agenda. Since every team works differently, it might not be fully applicable to you. Nevertheless, you can use it as a template or simply for inspiration.
Agenda example:
The biggest mistake I’ve made on many occasions was to not share the vision/roadmap/OKR, etc. during the planning. Every team member is busy with important tasks. If you’re an Engineer and you just worked on a complex task or fixed an important bug your thoughts may be somewhere else. Starting with a presentation on the priorities helps everyone to “arrive” and align on the priorities and goals. Being clear on the “why” will make the story-pulling part easier too. I usually take 5 minutes to present and remind each other of the main priorities including a Q&A session.
The sprint capacity helps scrum teams to define the availability of each team member during a sprint cycle. Knowing who will be on vacation or blocked by meetings and events will have an impact on the work being finished. The capacity is correlated to the velocity. The better teams plan capacity, the more accurate their velocity becomes. Not checking these numbers can lead to “surprises” during a sprint and eventually not achieving the sprint goal.
I’ve created a sprint capacity planning sheet that you can copy and use for your team. Let me know how it works for you. 🙂
At the beginning of my career, my teams and I weren’t estimating tickets. Therefore, we didn’t calculate the velocity based on previous sprints (sum of story points of all finished tickets). To be more specific: We didn’t look at any numbers at all. Obviously, it was more “fortune” than “skill” when we finished a sprint, which happened quite rarely.
During the very first sprint planning, it’s important to create a story point reference sheet to start getting a feeling for story point sizes and to learn after every sprint. Collecting data is an important part of the game that I wouldn’t neglect.
Related to unprepared backlogs, teams and Product Managers are often tempted to push or ignore the definition of ready. The main reason why? Usually deadlines. “It’s super important/urgent.” The price you pay for ignoring the definition of ready is usually that things take longer, and/or will be shipped out as low quality.
On top of that, teams can also be guilty of lying to themselves and manipulating their data. If you pull (or someone pushes) for example a ticket without estimation you destroy your velocity. That’ll lead to more inaccurate numbers… a decreasing team mood... I can go on for hours... 😐
If the ticket isn’t groomed and doesn’t contain all relevant information and acceptance criteria that’ll slow down the progress as well. What needs to be tested... How will it look (UI)... I can go on for hours again...
There are many reasons why teams don’t stick to an agenda. In the past, there were many times when I was incredibly busy and stuck in too many meetings right before the planning session with no preparation time. There’s one important piece of wisdom about following the agenda that I’ve learned:
Mastery comes with routine
Changing the routine regularly slows down the road to mastery. It’s important to adapt and change certain processes, and it’s important to try out things for a certain period. Unfortunately, teams often stop or change before they have really tried and gathered valid data. My recommendation is to make a plan, agree, and then stick to it á la “Build, Measure, Learn.”
Every team member can be the person who shares the backlog and pulls the stories. Even the Product Manager can do it as part of the team. It’s, however, better when someone from the Engineering side does this. As a Product Manager, you always want to get as many things done as possible. That can have a negative impact on the velocity because in most cases teams “pull” more than they can finish. Do I need to elaborate on that? 😉
My heart is two-sided on that topic. On the one hand, you‘ve got deadlines and you need to get things done. On the other hand, having a pushy attitude creates a lot of long-term debt. With good planning, you’ll avoid phasing situations where things and deadlines get too tight and things need to be pushed and rushed. I believe, depending on your business (B2C, B2B, etc.), the truth lies somewhere in the middle. When starting with the scrum and the first sprint planning(s) I recommend to rather pull less than too much. And when “shit hits the fan” in terms of something urgent popping up: Sit down with your team and discuss options and re-prioritize if needed.
After presenting the roadmap, checking the velocity and capacity, and reviewing the backlog items, many teams jump into technical planning. Even though that’s the perfect time to discuss and define some sprint goals. During the first sprint planning, I recommend not adding more than 2 sprint goals. That doesn’t mean that you’ll only work on two “things.” The sprint goal highlights the most important achievements a team wants to reach. The benefit of having clear sprint goals is that you need less discussion time on priorities during the sprint. Also, every team member is committed to achieving that.
Note: I’ve never added more than 3 goals with my teams.
I strongly believe a cool sprint name is very important. Taking 2 more minutes after the planning session to discuss a name is worth the time. I used to work with a team that needed to build a product import API. We called our sprint: “Mission importable”. It was our last sprint, and we wanted and had to finish the feature. Everyone was committed to it and we did it. You should have seen the proud faces of each team member when they presented the sprint results to their stakeholders. 😎
Don’t go too crazy though. We once called a sprint “We don’t give a ship” while we were building an API that sends/receives 3PL shipping data. The name wasn’t received very well by many stakeholders… especially when we didn’t finish the sprint.
There are some things that go wrong during a sprint planning session. On the other hand, many mistakes can be avoided through good preparation. That’s why I’ve created a sprint planning checklist. Download the free sprint planning checklist for better future meetings.
