Exercise files

Quick reference

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.

Instructions

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.

00:04Hi, this is Ray Sheen.

00:06Let's dig into the weeds for a few minutes and

00:08talk through what should happen in the first part of a Sprint planning meeting.

00:14Contrary to what some critics claim, a Sprint is not chaos.

00:17It is very organized.

00:19That organization starts with the Sprint planning meetings.

00:23This meeting is often divided into two parts,

00:25because there are two different objectives.

00:28In this session, I will address the first part, in the next session,

00:31I will discuss part two.

00:33The result of the first session is the selection of stories for

00:36the Sprint Backlog.

00:38The Product Owner comes to the meeting with their desired list but

00:41the Scrum Team must agree with the list.

00:43The Scrum Team can't reject something just because they don't like it but

00:47they can ask for clarification and there may be too many items on the list.

00:52Some of the stories on the Product Owner's Backlog list may be epics.

00:56That means the story is very large, and really needs to be divided into smaller

01:00chapters so that the work is more manageable and better understood.

01:04The Product Owner and Scrum Team work together to define the chapter stories.

01:09The Scrum Team will also identify infrastructure stories at this time.

01:13In fact, let's look a little closer at those stories.

01:17Infrastructure stories are very important to the success of the project, but

01:20they were not in the Product Backlog.

01:23The stories that the Product Owner has in the Product Backlog

01:26are those identified by stakeholders.

01:28We've talked about those quite a bit.

01:30However, for

01:31project work to be successful, often other activities must be done.

01:35The team may need to purchase some equipment and

01:37set it up in order to do testing and analysis.

01:40The team may need to complete audits or

01:42calibration activities in order to use key suppliers or instruments.

01:46These are not on the story cards that the Product Owner has but

01:49they must be done and done well.

01:51They are infrastructure stories added by the Scrum Team.

01:55The two most common reasons for

01:56these is to create a tester development system to work with, or to accomplish some

02:01compliance activities that are mandated by regulation or standards.

02:06The Scrum Team members must identify these because they are related to the approach

02:10that the team will use to accomplish the project.

02:13The Scrum Team can't use the excuse, they didn't fund us for that.

02:17If there's something they need, they must write the infrastructure story, and

02:21insert that story into the Sprint Backlog.

02:24An interesting point on large development projects, it quite possible that an early

02:29Sprint may be entirely devoted to doing infrastructure stories, especially

02:34if the project is using new technology that must be installed and tested.

02:40Now onto one of the most challenging elements of a Sprint planning meeting, and

02:43that is sizing the stories in the Sprint.

02:47The reason that the Scrum Teams sizes the stories is so

02:50that the Product Owner and the Scrum Team can agree on the stories

02:53that will create a minimally viable product and that can reasonably be

02:57exspected to be accomplished within the time period of the Sprint.

03:00Too many stories and the result is not minimally viable product.

03:04Too few and the Scrum Team is inefficiently waste time.

03:09But the challenge is how to size stories before the Scrum Team has had a chance to

03:13do some in-depth planning and estimating.

03:15The approach I recommend is that the Scrum Master reads through each story card and

03:20ensures that the Scrum Team understands it.

03:22The Scrum Master then asks the Product Owner and

03:25the Scrum Team members to each provide a size rating.

03:28If everyone is in agreement, the story and the size is well understood.

03:33If there is a big difference between the ratings,

03:36there's usually some confusion about the story, either what is needed or what must

03:40be done, either way everyone talks about it and you check the size again.

03:44This continues until you get close agreement.

03:48What do I mean by size ratings?

03:50It's a judgement call that's a guess about the amount of work needed to complete

03:54a story.

03:55There are many ways this can be done.

03:57The three most common are to use the t-shirt sizing of small, medium,

04:01large, extra large, and too big.

04:03The next is the doubling sequence.

04:06We start with the number one, and every value after that is doubled.

04:09So we get a sequence of 1, 2, 4, 8, 16, 32, etc.

04:13The third approach is my personal favorite

04:17just because of the elegance of the Fibonacci sequence.

04:21In this case,

04:22the previous value is added to the current value to get the next value.

04:26So the sequence is 1, 2, 3, 5, 8, 13, 21, 34, etc.

04:28Use whichever approach appeals to you and your team members.

04:37The way this works is that you either take one of the stories in the Sprint that

04:41everyone understands well, or you pick another activity that everyone knows and

04:45understands and you assign it a value from the sizing sequence.

04:49I recommend that you pick a medium to small activity so

04:52that the initial size story is labeled a size medium, or is a 4 or 5.

04:58The Scrum Master explains to everyone that this story is the reference story,

05:02and they should consider approximately how much work is in each story

05:06compared to the reference story.

05:09If it's half the amount of work, the size might be small, or 2.

05:13If it is twice as much work, it might be a large or 8.

05:18The Scrum Master asks everyone to give their estimate of size for each story.

05:23If the size estimate differs by two or more levels between the lowest and

05:27the highest, ask the individuals why they sized the story at that level.

05:32Usually, if there is two or more difference,

05:34it is because of a difference in the understanding of the story or

05:37different expectations on the Demo Criteria.

05:40Talk it through to get a better understanding and check the size again.

05:44The goal is to get everyone within one step difference.

05:48Once you have agreement, add up all your size scores and

05:51using the organization's velocity benchmark, determine if you should add or

05:55subtract stories to the Sprint Backlog.

05:59In the first few Sprints, these values may be all over the map

06:02until the team members become comfortable with the approach.

06:05This will be difficult for

06:06some because this is nothing like what is done in typical project planning meetings.

06:11At the end of this part of Sprint planning,

06:13you should have the complete Sprint Backlog.

06:18The first part of the Sprint planning meeting is used to organize the Sprint

06:22by selecting the stories to be done, including the infrastructure stories.

06:27By this time, the Scrum Team will probably need a quick break.

06:30Give them ten minutes to be back for the second part of Sprint planning.