Subscriber only lesson.
Sign up to this course to view this lesson.
Sprint Planning – Part 1
The first portion of the Sprint Planning meeting consists of selecting the Sprint Backlog and clarifying Stories.
When to Use Sprint Planning – Part 1
When each Sprint is about to begin, the Scrum Master, Product Owner and Scrum Team gather for the first portion of the Sprint planning activities.
- The Sprint Planning is divided into two parts with different purposes. Part 1 is to determine the Stories in the Sprint Backlog.
- The Sprint Planning Part 1 session should be attended by the Scrum Master, Product Owner and all the Scrum Team members.
- This is often the first meeting of the Scrum Team Members as a team.
- The Product Owner and the Scrum Team work together to agree on the Stories in the Sprint Backlog, the Scrum Master facilitates the meeting.
- The Product Owner starts with the Stories that he or she would like to have in the Sprint.
- Epic Stories are divided into Chapters.
- Epic stories are very large Stories. They are divided into a set of smaller “Chapter” Stories, each of which is recorded on a Story Card.
- Infrastructure Stories are added.
- Infrastructure Stories are activities and deliverables that the Scrum Team must do in order to complete the Stories from the Product Backlog.
- These often involve the acquisition, setup and testing of development or infrastructure assets such as test stations.
- These may also involve the completion of compliance activities that are not identified on a Product Backlog Story, but are required by standards such as a supplier audit.
- The Sprint Backlog Priority is set by the Product Owner, recognizing that Infrastructure Stories must be completed in time to support whatever other Story they are related to.
- Story sizing is then done.
- Stories are sized and the velocity measure is used to determine how many Stories should be in the Sprint Backlog. Stories not selected for the Backlog are still on the Scrum Board in the not selected column.
- Purpose of sizing is the improve understanding of the work of the Story and to establish a reasonable goal for the minimally viable product that is delivered at the end of the Sprint.
- The sizing is a judgement call by all Scrum Team members to estimate the amount of effort needed to complete a Story.
- When sizing a Story, the Story and Demo Criteria are read (usually by the Scrum Master) and the Scrum Team asks for clarifications from the Product Owner if needed.
- A rather small and well understood Story is selected first and used to calibrate the sizing. Once all Scrum Team members understand the Story, a size is assigned to it (usually a mid-range size) and all other stories are compared to the reference story.
- Each team member estimates the size of each Story by comparing it to the reference story and selecting an appropriate size:
- T Shirt size: small, medium, large, extra-large, too big)
- Doubles (1, 2, 4, 8, 16, 32, …)
- Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, …
- If team members disagree by more than two sizes, then the story is discussed in more detail until the team reaches an agreement.
- Once all sizing is done, the total of the sizes is added together and the velocity measure is used to determine how many Stories will likely be accomplished.
- The Sprint Backlog is reviewed to be certain that it creates a minimally viable product for the Sprint Demo. If not, the Stories selected for the Sprint are re-evaluated.
Hints and Tips
- This can become an intense meeting when there is a sharp difference of opinion on Story sizing and neither person wants to change. The Scrum Master must facilitate these situations. I recommend that when that happens, have the Product Owner and possibly another Scrum Team member talk through the Story to identify where the differences are.
- It is important that Scrum Team members agree on the reference Story and set a size for it. Some people have tendency to make everything small and other to make everything big. Setting the standard for “large” story and an “8” story will help to counter-balance that effect.
- Ensure the Scrum Team has identified all Infrastructure Stories. When there is a large sizing difference, it is often because one team member is assuming infrastructure work must be done and another team member is assuming it is in the Infrastructure Story.
- A new Scrum Team with team members who have not done this before will have often struggle with this activity since it is so different from typical project management activities.
Lesson notes are only available for subscribers.
PMI, PMP, CAPM and PMBOK are registered marks of the Project Management Institute, Inc.