Back to Blog List

Navigating the Scrum Events - Sprint Planning

Owen Strombeck
November 1, 2023
Subscribe

What is the ‘Navigating the Scrum Events’ Series?

If you or your team are new to Scrum, you can use this as a starting point to answer, “What should we be doing and why?” for each Scrum Event. If your team is more experienced but you feel like you’re drifting away from healthy behaviors and patterns and you’re not sure how to course correct - you can use this series as a baseline to reset and start re-aligning your team. This is NOT the end-all-be-all perfect way to operate for all scenarios - but a straight-to-the-point tactical list of steps to help you get to the basic outcomes you need at the end of the event.

 

Scrum Team in Sprint Planning

Sprint Planning - What’s The Point?

The basic purpose of Sprint Planning is for the Scrum Team to define a Sprint Goal and align around a plan for “what” and just enough of “how” they will achieve the Sprint Goal. The team is answering “why” with the goal, “what are we going to do” to reach the goal, and “how are we going to do it” through a plan, all resulting in the creation of a Sprint Backlog.

 

Ideally, the Product Owner (PO) brings a clear ‘why’ to the team from a business value perspective aligned with the Product Goal. The most basic answer to this might come in the form of a business priority or outcome that the Scrum Team is responsible for creating or working toward so that the Developers can build their plan for ‘what’ and ‘how’ in alignment with the Sprint Goal. 

 

Focus and Engagement

I highly recommend that someone from the team “drives” the Sprint Planning meeting. What I mean by this is a person who shares their screen (if the team is remote) or plugs into a conference room screen (if the team is in-person) or stands by the white-board to move sticky-notes around, etc... and brings up the backlog for the team to look at together. Anyone on the Scrum Team can take this on. It does not have to be the same person each Sprint. This person scribes and captures important bits of discussion and decisions during planning, prompts the team with questions and pushes the team forward through the steps below. Everyone else should do what they need to do (shut laptops, put chat on silent/do-not-disturb mode, etc..) in order to be fully focused and engaged in the planning session.

 

Sprint Planning Tactics

** Remember - the following isn’t the end-all-be-all perfect way to operate for all scenarios - but a straight-to-the-point tactical list of steps to help you get to the basic outcomes you need at the end of the event.

 

1. Have the PO set the stage

  • Share the business priority with the Scrum Team and communicate and clarify the value the team is creating or working toward. For example:
    • What is important to the business?
    • Why is it important to the business?
    • What opportunity are we capitalizing on?
  • Share any additional context that may help the Developers plan their ‘what’ and ‘how’
    • Are there significant dates or risk/reward situations related to the product?
    • Are there any explicit boundaries for this Sprint - things the team should NOT be worrying about?
  • Answer any high-level ‘why’ questions from the team

 

2. Create the Sprint Goal

 

3. Create and roughly order the Sprint Backlog

  • Start this process by asking the team “What are the absolute minimum things that we could do in order to meet our goal?”
    • If you already have a well-defined Product Backlog, pull the PBIs (Product Backlog items) you need from it into your Sprint Backlog.
    • Write new PBIs for anything the team identifies to achieve the Sprint Goal that isn’t already captured (just write down titles for new PBIs for now).
    • Remember that the Sprint Backlog doesn’t need to be perfect and isn’t set in stone at the end of Planning. The Sprint Backlog will evolve during the Sprint as the Developers learn from the work that they are doing focusing on delivering value tied to achieve the Sprint Goal.
  • Collaborate to adjust the order of the PBIs in the Sprint Backlog to reflect the Developer’s current best-guess as to what order would make sense to work on the PBIs. Don’t debate too much detail - just adjust the order to reflect a general sentiment of “probably this before that”.

 

4. Get each PBI in the Sprint Backlog Well-Defined

  • Starting at the top of the newly created and ordered Sprint Backlog, for each PBI:
    • Ask - “Should we split this PBI into multiple smaller items?”
    • Define the Acceptance Criteria by making a bullet-point list following the sentence “When this PBI is Done, the following will be true:”
    • Define boundaries or limits by making a bullet-point list following the sentence “This PBI does NOT include:”
    • PO - ask the team “What questions do you have for me about this item?”
      • Capture the answers in the PBI so they aren’t forgotten in a few days when someone picks up this item!
    • Team - have a quick discussion on “what is our current best guess for ‘how’ we are going to do this?”
      • This might be worth capturing in the PBI as well - NOT as a binding commitment of ‘we have to do it this way’ - but as a reminder of the collaboration and ideas the team had as a group.
      • How can you validate that each of your acceptance criteria are met?
    • Team - capture a size estimate on this PBI. For example, ask each member of the team to “throw” an estimate by holding up their hand with one, two, or five fingers showing where:
      • One = “I would be surprised if this takes longer than a day of focused work time”
      • Two = “I would be surprised if this takes longer than two days of focused work time”
      • Five = “I would be surprised if this takes longer than five days of focused work time”
      • These definitions of 1, 2 and 5 are a significant enough jump from each level to the next that if your team members throw different sizes, it is an indicator that more discussion is needed to align on understanding what this PBI represents and how the team is planning to complete it.
    • Ask again - “Should we split this PBI into multiple smaller items?”
      • Your discussion and notes on “how” are often useful in finding delineation points to split larger PBIs in multiple smaller PBIs.
      • Consider trying to break down your larger items into multiple smaller items. This can help with Daily Scrum conversations and focus for the team.
  • When you do identify items to split into multiple smaller items - take the opportunity to ask the team “Do we need all of these to accomplish our Sprint Goal? Could we move some of these smaller items out of this Sprint - back to the Product Backlog?”

 

5. Review the Sprint Backlog

  • Take a moment to review the entire Sprint Backlog as a team and ask them to throw a Fist to Five (or some other way to quickly gauge consensus) on “how confident are you that we are planned well enough to get started toward achieving the Sprint Goal?”
    • Closed fist = “Not at all - this is going to be an absolute disaster!”
    • One = “I think we have major problematic issues”
    • Two = “I think we have some small issues”
    • Three = “I’m not sure, but I don’t have specific questions or concerns”
    • Four = “I think we’re good”
    • Five = “We’re going to crush it!!” 
  • If you have any team members that held up less than three on the Fist to Five - discuss and iterate on the details of the Sprint Backlog until the team is all at three or higher

 

When Sprint Planning is Over...

When Sprint Planning is complete, the following should be true:

  • The team has clarity from the PO on the value they are helping create
  • The team has written a Sprint Goal that is clear and understood by all 
  • The Developers have alignment on how they plan to go about achieving their Sprint Goal
  • The Sprint Backlog contains PBIs that represent the team’s best guess at the things they need to do to accomplish the Sprint Goal
  • The PBIs in the Sprint Backlog are well-defined and well-understood by the team

 

Inspect and Adapt

Don’t stop now! Your team should be able to build a useful Sprint Backlog, but if you are just going through the motions over time you might fall victim to becoming stuck in Mechanical Scrum! Use your team’s retrospectives to inspect and adapt how your team is working together and continue to strive toward living the Scrum Values and true Professional Scrum. Here are some ideas of how to start making your Sprint Planning more effective.

What did you think about this post?

Share with your network