Story Planning

Story planning is a technique to facilitate commitment.
The ultimate goal of Story planning is to make a sprint planning that is really understandable and clear for every body. Something you understand so good that you can really feel whether it is doable or not. This is what you need to be able to commit. As a person and as a Team.
It’s a way to implement the Sprint planning and Sprint review session(s) and it serves as a great base for the standups and has proven to be very useful in many different cases.
When it’s hard to complete an entire story before the end of the Sprint.
When there are so many tasks in a Sprint that everyone has lost the overview.
When for some reason there is an anxiety to commit to a Sprint.
When planning a Sprint is taking a lot of time ( more than 1/2 hour/sprintweek )
The outcome of working with the Story planning is a highly focused and committed Team with maximal fun and productivity as a result.
To be succesfull in using the Story planning you should know a few things:
– in Story planning there are no tasks. There are Stories and a clear Definition of Done.
– the Story planning is updated every day during standup and communicated afterwards.
– planning is made based upon gut feeling. Not hours, nor story points.
– it’s a focus instrument. Not a planning instrument.
What’s the idea ?
The idea is to make a plan of the Sprint that uses the Team’s gut feeling on how many days it would cost them to complete a story. In an iterative way the entire Sprint will be planned. ( First version will be refined into a better version and so on). There is a strict timebox on this planning session of 1/2 hour per week. ( i.e. 1 hour for a two week sprint) because gut feeling is playing an important role and calculation should really be avoided.
Why does it work ?
It works because it gets the math out of the Teams heads. Just like you have a first impression when you meet someone and this often turns out to be right, the same goes for estimations. The Teams gut feeling on how much time it will cost them is often very close to reality.
Another reason why using a Story planning leeds to success, is because it only measures the most important thing : throughput time. Story planning focusses on finishing stories. It doesn’t matter how many activities can be done simultaneously or how hard the Team worked. The only thing that matters is ‘how many days did it cost to complete this story?’.
The biggest reason however is that it gives the Team insight in their planning and their real status at every moment of the Sprint.   This enables them to react upon this.
How to create a Story planning ?
Start with the highest prioritized story and ask the Team how many days it would cost them to complete this story according to the Definition of Done. It’s important that the entire Team answers this question and that the answer is based upon gut feeling. Not based upon a breakdown in tasks or a calculation based upon story points per day. Most teams know how much time it will take them within 30 seconds. With this information you can update the Story planning board and go on to the next story. Two assumption here : a)  the Team has pokered the story and, thus, knows what the story means and b) the Product Owner is present and refreshes everyones memory.
The story planning board has as many columns as there are working days in a Sprint ( e.g. for two week Sprints there are 10 columns ). Every column represents a working day and it’s header is therefor the name of the day of the week it represents. Column width should be exactly one post-it. So in the case where our first story would take the Team 2 days, the first two columns can be filled with a post-it that holds the name of this first user story.
Start a new row for every new story.
After a couple of minutes the story planning board will have one post-it in every column and as many rows as stories. Check with the Team whether this planning is really a realistic planning.
Now the first committed version of the Story planning is ready. And we’ve only spent 15 minutes creating it.
The second round consists of making overhead clear on the story planning board. Overhead like public holidays, individual holidays, part time days, ….
And then again ask the Team whether, with this new information on the board, the planning is still doable. Often it will be because of the fact that most of the times not everyone is on the critical path. When the Team can no longer commit to the planning because of someone on the critical path is off or there are too many public holidays you should adapt the planning untill the Team commits to it again.
The second committed version is now ready, and there was another 5 minutes needed to create it.
As said, in reality, it’s not always the case that every member of the Team can really add value to a story from the first moment it’s picked up until the moment it’s complete. It would be a pity to have these people do nothing. Therefore we have the third round of the story planning.
In this round the main question to answer for each story is “do we really need to wait to pickup this story until the previous one is completely ready?”. Or put differently “If you would start a day earlier on this story, would the previous one still be completed at the committed time?’. Because not every one is really adding value until the last moment, you can always start some stories earlier. Pick up the post-its of the story you want to accelerate and hang them back in the right columns. ( That’s why they all need their own row). Keep on shuffling and add new stories at the end where time comes free.
Finish with a realism check on the Team. “ Is this still something you would commit to ?”.
This is the third committed version of the story planning for this Sprint and we’re still within the hour !
Finally the planning must be actively challenged. Is it really doable to start with story x while you’re still working on story y ? On wednesday of the first week we have 4 stories in parallel. How will you organize this ? This can lead to some minor changes, but again, will end up in a committed version of the story planning.
Now the Team and Product Owner are ready to start the Sprint and every body clearly understands what will be done.
What about tasks and storypoints ?
It depends on the self organizing level of the Team whether they need tasks on post-its or whether they are able to work closely together and just deliver the story,   Anyhow, whenever using post-it tasks,  focus should remain on the story !    It’s never someone’s goal to finish a task.   The goal is at all time to complete a story.
Concerning storypoints:  To poker the stories is still very important because it gives the Team insight in what’s the story about and it offers the Product Owner a learning opportunity.   Storypoints are no longer used to determine the content of a Sprint.  However based on the past Sprints a prediction can be made for future Sprints.  This is particularly handy for the planning of releases.
How to use this as an instrument ?
First of all it’s an instrument to timebox the Sprint planning session. If all goes well the story planning is iterated four times into it’s final version, but don’t forget all intermediate versions are committed versions and therefore good enough to start the Sprint with.  So you can stop you planning session whenever time’s up.
It’s an instrument to bring focus in your standups. No more babble about tasks and what everyone did or achieve. Right to the heart: Where are we with the story that’s on today? We said it would be 2 days. Will it be finished tomorrow ? More on this in my blog on effective standups.
Don’t forget to update the Story planning !
A post-it that has been completed gets a completion mark ( a curl or a green dot ), a post-it that suffers a delay gets another mark ( e.g. red dot). If a story now takes 3 days in stead of 2, add a post-it and check whether the rest of the planning is still ok. ( and vice versa).  You can even add the reason why there’s need of an extra day on this new post-it to make the picture complete.
It’s also an instrument to communicate real status in a transparant way. The problem with burn down charts is that a flat line is not saying anything. You can draw a burndown on all kinds of things like tasks or estimated hours but neither tasks nor hours are adding any real value so there shouldn’t be any effort put in measuring them, and you definitely shouldn’t use them to measure progress.
Story planning offers real insight in the complete Sprint planning. It shows for every story whether it has been started, completed or delayed.
As an instrument for the Sprint review, the Story planning can be used as the agenda. Go from the top left corner to the right bottom corner and demo each story.
Pitfall
You might have noticed that a Story planning looks a little bit like a Gantt chart. It does ! But just from the outside. The moment a Story planning starts being used like a Gantt chart it will fail. Unlike a Gantt chart, the heart of Story planning is not about predictability. It’s about the gut feeling of the team with all their knowledge at that moment in time AND it’s about what should be the focus of the Team for today. Nothing more. Nothing less.