Sprint Planning April 2018

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

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

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

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

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

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)

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

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

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

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