1. Sprint Planning
April 2018

2. Agenda Let’s get started What is Sprint Planning?
Timing and Participants
Getting Ready
Making sure we have the right inputs
One Part or Two Parts?
Capacity
How do we select Backlog Items?
Gaining confidence and making a commitment

3. Sprint Planning- General Context
We build a release by building increments of work from the Product Backlog through multiple Sprints
Once we have built and tested the functionality we planned for the release, and the Product Owner has accepted the results from each Sprint, we are ready to go live

4. What is Sprint Planning?
Scrum team defines a goal for the Sprint
Development team determines which backlog items are aligned with that goal
Dev team determines which of those backlog items from #2 above it can realistically deliver by the end of the Sprint
Dev team develops a plan for how to complete the backlog items for the Sprint

5. Timing and Participants
Recurring, “just in time” activity done on Day 1 of the new Sprint
Scrum.org says that it should take 8 hours or less for a 4 week long Sprint, proportionately less for shorter Sprints
The whole Scrum team collaborates during Sprint Planning
The Product Owner shares the goal of the Sprint, presents the prioritized backlog items and answers questions
The Dev team reviews prioritized backlog items and determines what it can realistically deliver- the result at end of Sprint planning would be a “Sprint Commit” or commitment by the Dev team to complete (build and test and integrate) backlog items targeted in the Sprint
Scrum Master role is to be the facilitator, guardian of the Scrum process, ask probing questions, challenge the Dev team commitment to make sure it makes sense/is realistic

6. Getting Ready Sample DOR
Backlog items targeted for the Sprint must meet the Scrum team’s Definition of Ready” (DOR)
We also need the Product Owner to have a really great idea on what he/she wants in the Sprint- and must be able to articulate it
At the end of the Sprint, I would [a user, or customer or …] to be able to …[do this]
Or have a specific set of User Stories in mind from the backlog
Ultimately, the Dev team needs to understand the Sprint goal and commit that they can do the work in the Sprint

7. Making sure we have the right inputs
“Ready” state for the top most product backlog items
Average team velocity based on prior Sprints or predicted velocity
Business or Technical Constraints
Team capabilities and skills needed vs. available
Challenge question: How do we handle situations where we don’t have the right skill set for this particular Sprint ?
Raise as an impediment
Initial Sprint Goal/business goal (If no formal Sprint goal is available, we select items from the top of the backlog, where the highest priority items would be groomed and refined, and work our way down)

8. What to do in the Sprint Planning Meeting
Discuss the “What” and “how”
Dev team calculates available capacity
If planned backlog items do not fit within the capacity, Sprint goal would need to be adjusted
Dev team selects the backlog items which support that Sprint goal
Dev team calculates capacity and forecasts the product backlog items the Dev team believes it can deliver by the end of the Sprint
The Dev team creates a plan, breaking down the User Stories into tasks and then estimating the level of effort hours for each task
The team compares the level of effort total hours to the capacity they calculated in the first part
If the Dev team is confident that it can commit to completing the work targeted for the Sprint, they commit to the Sprint Backlog
If the Dev team does not feel confident, the forecast and Sprint goals should be refined to fit the capacity
Backlog items which are not committed to stay in the Product Backlog
What to do in the Sprint Planning Meeting

9. Capacity Guides us on what we can deliver
Make sure we account for non-Scrum Activities, planned time off
Need buffer for things going wrong, challenges
Having a buffer is a good practice, because there will challenges we will encounter
Can estimate for the first Sprint, and then take actual empirical evidence to understand the ideal buffer for development uncertainty
Capacity can be calculated using Story Points or Hours
Option 1- Story Points, since this is how the Backlog is sized
Capacity in Story Points can also be used to express our velocity
Can adjust based on actual velocity from prior Sprints, or predicting velocity
Option 2- Effort Hours
Use a range of hours per day per resource (we had covered this in earlier lessons)
Calculate available effort hours range
Don’t estimate based on best case, highest effort hours capacity

10. How do we select Backlog items?
If there is a formal Sprint goal, we would identify user stories which align with the goal
If not formal goal, we start with the User Stories at the top of the backlog and work our way down
If a User Story is too big to fit in the capacity we have calculated, or if there is a skills gap, we skip that and move to the next User Story
Golden rule: Don’t start what we cannot finish!
Break down the User Story to smaller pieces which can fit in the Sprint capacity
Consider working on the next priority item (s)
This is a perfect opportunity to evaluate the User Story we are targeting against the Definition of Ready before we pull it into the Sprint and commit to it
Doing partial work in a Sprint to finish the rest in another Sprint “violates” the “potentially shippable product increment” goal for each Sprint

11. Gaining confidence and making a commitment
We gain confidence by having a plan, and tasks which identify the work we need to do and how long it is going to take vs. the capacity we have calculated
We don’t plan for best case scenarios or worse case scenarios, but somewhere in the middle
Having some Sprints completed will give us more knowledge so we can pivot and adjust
When we break down tasks, we also will be able to see if we might have skills gaps and recalibrate as needed
We generally do not want to assign individual names to each task- potential waste of time as things change and updates would have to be made to the task list
We have to be careful for skills gaps within the capacity we have calculated- this can cause us to rethink a specific User Story
For this reason, we may have to revise the initial Sprint Goal
Once planning is done, the Dev team “commits” to the business value it will deliver at the end of the Sprint (sometimes, “Business Value Forecast” is used instead of Business Value Commitment”
Output from Sprint Planning: a plan for how to achieve the Sprint goal