What is Sprint Planning?

Sprint Planning is a formal Scrum Event that should define the beginning of the Sprint.  In Sprint Planning, the Product Owner suggests a Sprint Goal for the Scrum Team to commit to over the Sprint.  The Developers then negotiate the size of the Sprint Goal – if the Sprint Goal is too big, or too small, the Product Owner and Developers work on defining a right-sized Sprint Goal for the Sprint.  This is called The Why (also called Sprint Planning Part 1).

Sprint Planning Part 2, or The What, takes place next.  This is when the Developers and Product Owner Inspect the Product Backlog to find Product Backlog Items (PBI’s) that are Ready to be worked on, AND that match the Sprint Goal.  If there are PBI’s that match the Sprint Goal, are necessary for meeting the Sprint Goal, and are not Ready, then it’s the Scrum Team’s job to get the those PBI’s ready.  When the necessary PBI’s are selected, they are moved to the Sprint Backlog.

Finally, Sprint Planning Part 3, or The How, takes place.  This is when the Developers discuss HOW to get the work done for the Sprint.  This can be accomplished many different ways.  Possibly the most popular way to do this is for the Developers to approach each PBI individually, and break it down into achievable (and small) tasks.  Another fairly popular way of doing this is for the Developers to visualize the Sprint Goal as a target destination, and the Sprint as the journey.  They then list out all of the necessary tasks they must accomplish on the journey (not necessarily linking those tasks to individual PBI’s).  Either way, the tasks are added to the Sprint Backlog.

Need a How-To on Sprint Planning?

If you are new to Scrum, and don’t have any clue how to plan a Sprint, I offer this How-To to you.  This is a very ‘dumbed down’ version that experienced Scrummers might find to be a waste of their time.  But for you, True Beginner, I would like you to open your mind and see how we approach the CONCEPT of Sprint Planning.

If you are experienced in Scrum, here is a more tactical explanation of Sprint Planning that may be more to your liking.

Our normal work week is 9 to 5, Monday through Friday.  That seems to be a good time frame of getting a block of related work done, so let’s use that as our Sprint.
A Sprint is merely a timebox, or a set amount of time for getting something done.  Sprints are never lengthened, and we always start them on time.  So, a regular work week really seems to work well for us.
Most of us know how much work we can get done in a week.  Let’s show that with this empty box.  If we don’t know how much we can get done in a week, we’ll adjust the size of the box next time we go into Sprint Planning.
The stuff we need to do, in Scrum, are called Product Backlog Items.
…Or PBI for short.  Let’s let a small rectangle represent our PBI’s.
Not all rectangles are the same size, and neither are PBI’s.  So, let’s say the height of a PBI is how hard it is to complete.
…And the width is how long we think it will take to complete it.
When we have a group of PBI’s that we need to complete, they often look like this.  Lot’s of differently sized things, where some are smaller and others are bigger.  As long as nothing is too big to fit into our Sprint, we are fine.  If something doesn’t fit into our Sprint, we need to break it up into smaller PBI’s that make sense to deliver individually.
Most people like to label their work.  It makes it a little easier to track.
Now, using what ever method or means you find necessary, fit all of the PBI’s into your Sprint.  If you know they will all fit, but you are having trouble, try different combinations or configurations.  Move things around.

This is what our example looks like.

How much room do you have left?  How much room should you have left over?  Only experience can lead you to an acceptable answer to that question.  The general advice, though, is to leave enough room in your Sprint to handle last minute problems.
If it helps to visualize how much space you have open in the Sprint, shade in the empty space.
Most experienced coaches and trainers will tell you not to worry with scheduling the work in a Sprint.
Not to trivialize this supposed need, here’s a way that may help.  Draw the days of the week, equally spaced, over the top of your Sprint.  Extend the lines between the days down through the sprint.

For each day, you can see that less and less time is dedicated to PBI’s.  Why?  The space we left open, for last minute problems, will compound daily.  And, it may move things from Tuesday to Wednesday, and so on.  If we recognize this natural phenomenon, and we allow for it in our plans, then we can adjust to its affects easier.

Here, you can see that Friday is completely open.  This actually helps Scrum teams, because the last day of each Sprint is usually dominated by the Sprint Review, Sprint Retrospective, and possibly the next Sprint’s Sprint Planning.