Sprint Planning

Prepare for Sprint Planning
It's important to make sure the product backlog is in shipshape //before// the sprint planning meeting. This means:
 * The product backlog should exist
 * There should be one product backlog and one product owner
 * All important items should have importance ratings assigned to them, different importance ratings.
 * It is OK if lower-importance items all have the same value, since they probably won't be brought up during the sprint planning meeting anyway.
 * Any story that the product owner believes has a remote possibility of being included in the next sprint should have a unique importance level.
 * The importance rating is only used to sort the items by importance. So if Item A has importance 20 and Item B has importance 100, that simply means B is more important than A. If B had importance rating 21 it will still mean the exact same thing.
 * It's useful to leave gaps in teh number sequence in case an item C comes up that is more important than A but less important than B.
 * The product owner should //understand// each story (normally he's the author, but in some cases other people add requests, which the product owner can prioritize).


 * Note:** Other people than the product owner may add stories to the product backlog. But they may not assign an importance level, that is the product owner's sole right. They may not add time estimates either, that is the team's sole right.

Do Sprint Planning
Sprint planning is probably the most important event in Scrum. A badly executed sprint planning meeting can mess up a whole sprint.

The Purpose of the sprint planning meeting is to give the team enough information to be able to work in undisturbed peace for a few weeks, and to give the product owner enough confidence to let them do so. The concrete output is:
 * A sprint goal.
 * A list of team members (and their commitment levels, if not 100%).
 * A sprint backlog (a list of stories included in the sprint).
 * A defined sprint demo date.
 * A defined time and place for the daily scrum.

The reason why the whole team and the product owner have to be at the sprint planning meeting is because each story contains three variables that are highly dependent on each other:
 * Scope - set by the product owner
 * Importance - set by the product owner
 * Estimate - set by the team

During a sprint planning meeting, these three variables are fine-tuned continuously through face-to-face dialog between the team and the product owner.

Normally the product owner starts the meeting by summarizing his goal for the sprint and the most important stories. Next, the team goes through and time-estimates each story, starting with the most important one. As they do this, they will come up with important scope questions - "does this Delete User-story include going through each pending transaction for that user and canceling it?" In some cases the answers will be surprising to the team, prompting them to change their estimates.

In some cases the time estimate for a story won't be what the product owner expected. This may prompt him to change the importance of the story. Or change the scope of the story, which in turn will cause the team to re-estimate, etc.

This type of direct collaboration is fundamental to Scrum and, in fact, all agile software development.

What is the product owner insists that he doesn't have time to join sprint planning meetings? "I've already listed what I want." Try one of the following strategies, in the given order:
 * Try to help the rpoduct owner understand why his direct participation is crucial and hope that he changes his mind.
 * Try to get someone in the team to volunteer as product owner proxy during the meeting. Tell the product owner "Since you can't join our meeting, we will let someone here represent you as a proxy. He will be fully empowered to change priorities and scope of stories on your behalf during the meeting. I suggest you synchronize with him as much as possible before the meeting. Please suggest someone else to represent you, as long as that person can join us for the full length of the meeting."
 * Try to convince the management team to assign a new product owner.
 * Postpone the sprint launch until the product owner finds time to join the meeting. In the meantime, refuse to commit to any deliveries. Let the team spend each day doing whatever they feel is most important that day.

Quality is not negotiable
Try to distinguish between //internal quality// and //external quality//:
 * //External quality// is what is perceived by the users of the system. A slow and non-intuitive user interface is an example of poor external quality.
 * //Internal quality// refers to issues that usually aren't visible to the user, but which have a profound effect on the maintainability of the system. Things like system design consistency, test coverage, code readability, refactoring, etc.

Generally, a system with high internal quality can still have a low external quality. But a system with low internal quality will rarely have a high external quality.

External quality can be up for discussion. In some cases it might make perfect business sense to release a version of the system that has a clumsy and slow UI, and then release a cleaned up version later. Leave that trade-off to the product owner, since he's responsible for determining scope.

Internal quality is not up for discussion. It's the team's responsibility to maintain the system's quality under all circumstances and this is simply not negotiable. Ever.

Sacrificing internal quality is almost always a terrible, terrible idea. The time saved is far outweighted by the cost in both short and long term. Once a code base is permitted to start deteriorating is is very hard to put the quality back in later.

Instead, try to steer the discussion towards scope instead. "Since it's important for you to get this feature out early, can we reduce the scope so that it will be quicker to implement?"

Once the product owner has learned that internal quality isn't negotiable he usually gets quite good at manipulating the other variables instead.

Sprint Planning Meeting
Everything in Scrum is time-boxed, including the sprint planning meeting. Try hard to stick to this simple, consistent rule. Still, the most difficult thing about sprint planning meetings is that they can drag out in time. This happens over and over, especially for new teams.

To deal with this, you can cut the meeting short. Tell the team and the product owner that the meeting will end soon. Are the results satisfactory, or should another meeting be scheduled? Probably the most effective way is to cut it short and let the sprint suffer. The upside, however, is that the team has learned a very valuable lesson, and the next sprint planning meeting will be much more efficient. In addition, people will be less resistant when you propose a meeting length that they previously would have thought was too long.

Learn to keep your time-boxes, learn to set realistic time-box lengths. That applies both to meeting lengths and sprint lengths.

Sprint Planning Meeting Agenda
Having some kind of preliminary schedule for the sprint planning meeting will reduce the risk of breaking the timebox. An example of a typical schedule can be as follows:
 * **1300-1330:** Product owner goes through sprint goal and summarized product backlog. Demo place, date and time is set.
 * **1330-1500:** Team time-estimates, and breaks down items as necessary. Product owner updates importance ratings as necessary. Items are clarified. "How to demo" is filled in for all high-importance items.
 * **1500-1600:** Team selects stories to be included in sprint. Do velocity calculations as a reality check.
 * **1600-1700:** Select time and place for daily scrum (if different from last sprint). Further breakdown of stories into tasks.

Sprint Length
One of the outputs of the sprint planning meeting is a defined sprint demo date. That means you have to decide on a sprint length.

Short sprints are good. They allow the company to be agile, i.e. change direction often. Short sprints = short feedback cycle = more frequent deliveries = more frequent customer feedback = less time spent running in the wrong direction = learn and improve faster, etc.

Long sprints are good too. The team gets more time to build up momentum, they get more room to recover from problems and still make the sprint goal, you get less overhead in terms of sprint planning meetings, demos, etc.

In general, product owners like short sprints and developers like long sprints. 3 weeks is short enough to give us adequate corporate agility, long enough for the team to achieve flow and recover from problems that pop up in the sprint.

Do experiment with sprint lengths initially. Don't waste too much time analyzing, just select a decent length and give it a shot for a sprint or two, then change length.

However, once you have decided what length you like best, stick to it for an extended period of time. By keeping the same length this becomes like a corporate heartbeat which everyone comfortably settles into.

Defining the Sprint Goal
For some reason it's hard to come up with a sprint goal. But still, it's better to have a half-crappy goal than none at all. The important thing is that it should be in business terms, not technical terms, so that people outside the team can understand.

The sprint goal should answer the fundamental question "Why are we doing this sprint? Why don't we all just go on vacation instead?" The goal should not already been achieved.

The sprint goal may seem secondary during the sprint planning, but it often comes to use in mid-sprint when people are starting to get confused about what they should be doing. If you have several Scrum teams working on different products it's very useful to be able to list the sprint goals of all teams on a single wiki page and put them up on a prominent space so that everybody in the company knows what the company is doing - and why.

Which Stories to Include in the Sprint
One of the main activities of the sprint planning meeting is to decide which stories to include in the sprint. More specifically, which stories from the product backlog to copy to the sprint backlog.

Thea team decides how many stories to include in the sprint. Not the product owner or anybody else. If, however, the product owner tries to affect the decisions made by the team and include another story to the sprint backlog, consider the following:
 * **Reprioritize:** Reprioritize so that a specific story is prioritized over other stories. This means another story will be left out.
 * **Change the scope:** Reduce the scope of a story until the team believes that another story will fit into the sprint.
 * **Split a story:** The product owner might decide that there are some aspects of a story that really aren't that important, so he splits this stories into two stories with different importance levels.

When the team decides which stories to include in the sprint, a team can use their gut feel. They get a feeling of which stories that can be completed in the sprint. Start at the highest priority and work downwards. This technique works pretty well for small teams and short sprints.

Velocity Calculations
Velocity is a measurement of "amount of work done", where each item is weighted in terms of its initial estimate.

Velocity calculations produce crude numbers, but it's still a useful number, especially when compared to nothing at all. It gives you some hard facts. Regardless of the reasons, you get a approximate difference between how much we thought we would get done and how much we actually got done.

Stories that got almost completed during a sprint has a value of zero. Scrum is all about getting stuff completely, shippable, done. See Donald Reinertsen's "Managing the Design Factory" or one of Poppendieck's books for more on that.

One very simple way is to look at the team's history. What was their velocity during the past few sprints? Then assume that the velocity will be roughly the same next sprint. It is only feasible for teams that always have the same size and same working conditions etc. This is fo course not always the case.

A more sophisticated variant is to do a simple resource calculation to calculate number of available man-days that the team can produce. An ideal man-day is a perfectly effective, undisturbed day, which is rare. Furthermore, we have to take into account things such as unplanned work being added to the sprint, people being sick, etc. We use the term "focus factor" for this.

This factor is an estimate of how focused the team is. A low focus factor may mean that the team expects to have many disturbances or expects their own time estimates to be optimistic.

The best way to determine a reasonable focus factor is to look at the last sprint (or even better, average the last few sprints).

This is the sum of the initial estimates of all stories that were completed last sprint. A good starting point can be to set the focus factor at 70%.

To have a good estimate, first do velocity calculation and then do a gut feeling to ignore the numbers and just think about if this feels realistic. If it feels like too much, remove a story or two. And vice versa.

At the end of the day, the goal is simply to decide which stories to include in the sprint. Focus factor, resource availability, and estimated velocity are just a means to achieve that end.

Index Cards
Most of sprint planning meeting is spent dealing with stories in the product backlog. Estimating them, reprioritizing them, clarifying them, breaking them down, etc.

Use of Excel on a big screen with either the product owner or scrum master doing the editing while each story is discussed isn't a good solution.

A solution that works much better is to create //index cards// and put them up on a wall (or a large table). This is a superior user interface compared to computer and projector because:
 * People stand up and walk around. They stay awake and alert longer.
 * Everybody feels more personally involved (rather than just the guy with the keyboard).
 * Multiple stories can be edited simultaneously.
 * Reprioritizing is trivial - just move the index cards around.
 * After the meeting, the index cards can be carried right off to the team room and be used as a wall-based taskboard.

You can either write them by hand or use a simple script to generate printable index cards directly from the product backlog.

It is important that the scrum master manually updates the Excel-based product backlog with respect to any changes that were made to the physical story index cards. Yes, this is a slight administrative hassle but we find this perfectly acceptable considering how much more efficient the sprint planning meeting is with physical index cards.

Time estimates are usually easier to do (and more accurate) if a story is broken down into tasks. This is also nice and easy to do with our index cards. You can have the team divide into pairs and break down one story each, in parallel.

Do this by adding little post-it notes under each story, each post-it reflecting one task within that story. Don't update the Excel-based product backlog with respect to the task breakdowns, for two reasons:
 * The task breakdown is usually quite volatile, i.e. they are frequently changed and refined during the sprint, so it is too much of a hassle to keep the product backlog Excel synchronized.
 * The product owner doesn't need to be involved at this level of detail anyway.

Just as with the story index cards, the task breakdowns post-its can be directly reused in the sprint backlog.

Definition of "Done"
It is important that the product owner and the team agree on a clear definition of "done". Is a story complete when all code is checked in? Or is it complete only when it has been deployed to a test environment and verified by an integration test team? Whenever possible we use the done definition "ready to deploy to production" but sometimes we have to make do with the done definition "deployed on test server and ready for acceptance test".

It is good enough to say that "a story is done when the tester in the Scrum team says so". It is then up to the tester to make sure that product owner's intent is understood by the team, and that the item is "done" enough to pass the accepted definition of done.

All stories can't be treated the same. A story named "Query users form" will be treated very differently from a story named "Operations manual". In the latter case, the definition of "done" might simply mean "accepted by the operations team". That is why common sense is often better than formal checklists.

If you often run into confusion about the definition of done you probably should have a "definition of done" field on each individual story.

Time Estimating using Planning Poker
In order to provide an estimate for each story, a team member needs some kind of understanding of what the story is about. By asking everybody to estimate each item, we make sure that each team member understands what each item is about. This increases the likelihood that team members will help each other out during the sprint. This also increases the likelihood that important questions about the story come up early.

When asking everybody to estimate a story we often discover discrepancies where two different team members have wildly different estimates for the same story. That kind of stuff is better to discover and discuss earlier than later.

If you ask the team to provide an estimate, normally the person who understands the story best will be the first one to blurt one out. Unfortunately, this will strongly affect everybody else's estimates.

There's an excellent technique to avoid this - it is called planning poker. Each team member gets a deck of 13 cards with different values. Whenever a story is to be estimated, each team member selects a card that represents his time estimate (in story points) and places it face-down on the table. When all team members are done the cards on the table are revealed simultaneously. That way each team member is forced to think for himself rather than lean on somebody else's estimate.

If there's a large discrepancy between two estimates, the team discusses the differences and tries to build a common picture of what work is involved in the story. They might do some kind of task breakdown. Afterwards, the team estimates again. This loop is repeated until the time estimates converge, i.e. all estimates are approximately the same for that story.

The following values are used:
 * 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, "coffee-cup"

Note that the number sequence is non-linear. For example, there is nothing between 40 and 100. This is to avoid a false sense of accuracy for large time estimates. All we know is that it is a large story and that it is hard to estimate. If you want more detailed estimates, split the story into smaller stories and estimate the smaller stories instead.

Some special cards to note:
 * 0 = "this story is already done" or "this story is pretty much nothing, just a few minutes of work".
 * ? = "I have absolutely no idea at all. None."
 * Coffee cup = "I'm to tired to think. Let's take a short break."

Clarifying Stories
How do you ensure that the product owner's understanding of a story matches the team's understanding? Or that each team member has the same understanding of each story? Well, you can't.

There are some simple techniques for identifying the most blatant misunderstandings. The simplest technique is simply to make sure that all the fields are filled in for each story (or more specifically, for each story that has high enough importance to be considered for this sprint).

Consider the following:
 * A missing estimate can easily lead to misunderstandings.
 * The field "how to demo" is empty. Discuss it and it can clarify things.

The "how to demo" description of a story can (and should) be very brief. Otherwise you won't finish the sprint planning meeting on time. It is basically a high level description of how to execute the most typical test scenario manually. "Do this, then that, then verify this". A simple description often uncovers important misunderstandings about the scope of a story.

Breaking Down Stories into Smaller Stories
Stories shouldn't be too small or too big (in terms of estimates). If you have a lot of 0.5-point stories you are probably going to be a victim of micromanagement. On the other hand, a 40-point story stands a high risk of ending up partially complete, which produces no value to your company and just increases administration.

It is almost always possible to break a large story into smaller stories. Just make sure that the smaller stories still represent deliverables with business value.

We normally strive for stories weighted 2-8 man-days. Our velocity is usually around 40-60 for a typical team, so that gives us somewhere around 10 stories per sprint. Sometimes as few as 5 and sometimes as many as 15. That's a manageable number of index cards to deal with.

Breaking Down Stories into Tasks
Stories are deliverable stuff that the product owner cares about. Tasks are non-deliverable stuff, or stuff that the product owner doesn't care about.

Example of breaking down a story into tasks:
 * Story: "Query users"
 * Tasks: "Clarify requirements", "Write test case", "Design UI", "Find reporting tool & do spike", "Implement the user list", "Integration, test, debug, refactor", "Implement the query form"

Some interesting observations:
 * New Scrum teams are reluctant to spending time breaking down a bunch of stories into tasks up-front like this. Some feel this is a waterfall-ish approach.
 * For clearly understood stories, it is just as easy to do this breakdown up-front as it is to do later.
 * This type of breakdown often reveals additional work that causes the time estimate to go up, and thereby gives a more realistic sprint plan.
 * This type of breakdown up-front makes daily scrum meetings noticeably more efficient.
 * Even if the breakdown is inaccurate and will change once work starts, the above advantages still apply.

Try to make the sprint planning time-box long enough to fit this in, but if time runs out let it drop out.

Note - we practice TDD (Test-driven Development) which in effect means that the first task for almost each story is "write a failing test" and the last task is "refactor" (improve code readability and remove duplication).

Sprint Planning Priorities
During sprint planning, what can be cut out if we run out of time?. Use the following priority list:
 * **Priority 1:** Sprint goal and demo date is absolutely necessary to start a sprint. The team has a goal, an end date, and they can work right off the product backlog. However, to start a sprint with this little info is not recommended.
 * **Priority 2:** A list of which stories the team has accepted for this sprint.
 * **Priority 3:** Estimate filled in for each story in sprint.
 * **Priority 4:** "How to demo" filled in for each story in sprint.
 * **Priority 5:** Velocity & resource calculations, as a reality check for your sprint plan. Includes list of team members and their commitments (otherwise you can't calculate velocity).
 * **Priority 6:** Specified time and place for daily scrum. If you run out of time the Scrum master can simply decide this after the meeting and email everyone.
 * **Priority 7:** Stories broken down into tasks. This breakdown can instead be done on a daily basis in conjunction with daily scrums, but will slightly disrupt the flow of the sprint.

Tech Stories
Tech stories are stuff that needs to be down but that is not deliverable, not directly related to any specific stories, and not of direct value to the product owner.

For example:
 * **Install continuous build server**
 * Why: Because it saves immense amounts of time for the developers and reduces the risk of big-bang integration problems at the end of an iteration.
 * **Write a system design overview**
 * Why: Because developers keep forgetting the overall design, and thereby write inconsistent code. Need a "the big picture" document to keep everyone on the same page designwise.
 * **Refactor the DAO layer**
 * Why: Because the DAO layer has gotten really messy and is costing everyone time due to confusion and unnecessary bugs. Cleaning the code up will save time for everyone and improve the robustness of the system.
 * **Upgrade Jira** (bug-tracker)
 * Why: The current version is too buggy and slow, upgrading will save everyone time.

Treating tech stories as first-class stories is no good. The product owner tends to give them low priorities. In some cases the product owner is right, but often not, since he's not always qualified to be making that trade-off. Try to handle tech stories according to the following list: - Look hard for a way to transform a tech story into a normal story with measurable business value. That way the product owner has a better chance to make correct trade-offs. - If we can't transform a tech story into a normal story, see if the work could be done as a task within another story. For example "refactor the DAO layer" could be a task within the story "edit user", since that involves the DAO layer. - If both of the above fail, define it as a tach story, and keep a separate list of such stories. Let the product owner see it but not edit it. Use the "focus factor" and "estimated velocity" parameters to negotiate with the product owner and bend out some time in the sprint to implement tech stories.

Example:
 * Team:** “We have some internal tech stuff that needs to be done. We would like to budget 10% of our time for that, i.e. reduce focus factor from 75% to 65%. Is that OK?”
 * **Product owner:** “Hell no! We don’t have time!”
 * **Team:** “Well, look at the last sprint (all heads turn to the velocity scrawls on the whiteboard). Our estimated velocity was 80, and our actual velocity was 30, right?”
 * **Product owner:** “Exactly! So we don’t have time to do internal tech stuff! Need new features!”
 * **Team:** “Well, the reason why our velocity turned out to be so bad was because we spent so much time trying to put together consistent releases for testing”.
 * **Product Owner:** “Yes, and?”
 * **Team:** “Well, our velocity will probably continue being that bad if we don’t do something about it.”
 * **Product Owner:** “Yes, and?”
 * **Team:** “So we propose that we take approximately 10% off of this sprint to set up a continuous build server and other stuff that will take the pain off of integration. This will probably increase our sprint velocity by at least 20% for each subsequent sprint, forever!”
 * **Product Owner:** “Oh really? Why didn’t we do this last sprint then?!”
 * **Team:** “Er... because you didn’t want us to...”
 * **Product Owner:** “Oh, um, well fine, sounds like a good idea to do it now then!”

Of course, the other option is to just keep the product owner out of the loop or give him a non-negotiable focus factor. But there's no excuse not to try to reach consensus first.

If the product owner is competent and reasonable try keeping him as informed as possible and letting him make the overall priorities. Transparency is one of the core values of Scrum.

Bug Tracking System vs. Product Backlog
How do you bring bugs (e.g. with Jira) into the sprint planning meeting? - Product owner prints out the most high priority Jira items, brings them to the sprint planning meeting, and puts them up on the wall together with the other stories (thereby implicitly specifying the priority of these items compared to the other stories). - Bug-fixing is considered to be outside of the sprint, i.e. the team keeps a low enough focus factor (e.g. 50% to ensure that they have time to fix bugs. It is then simply assumed that the team will spend a certain amount of time each sprint fixing Jira-reported bugs.

The first one may be preferred due to its simplicity.

Sprint Planning Meeting is Finally Over
The sprint planning meeting is the most important thing you do in Scrum. Spend a lot of effort getting that right, and the rest will be so much easier.

The sprint planning meeting is successful if everyone (all team members and the product owner) exit the meeting with a smile, and wake up the next morning with a smile, and do their first daily scrum with a smile.