The Story Grid – A Simple Sprint Planning Technique
I have two main techniques I utilise when carrying out sprint planning. One is the effective and venerable Planning Poker. The other technique didn’t even have a name until today as I had to name it in order to write about it. However, it is just as integral as Planning Poker to the sprint planning sessions I run and has been a feature in them for more than a year. I have decided to call it The Story Grid but should point out that I didn’t come up with the actual idea. It was a suggested to me by Scrum Coach Martine Devos and, as far as I am aware, was a completely off the cuff idea from Martine intended to solve an issue our team was having with sprint planning.
The issue that we were having was that, in the heat of sprint planning, it was tricky to keep a track of when the team had reached their forecast capacity for the sprint. I, as ScrumMaster, could keep a running total of planned story points versus capacity but this was tedious to do and held in my head or on a piece of paper. The solution was to maintain a visual representation of the planned stories versus the total time available in the sprint which everyone could see: The Story Grid.
The idea is simple. First comes the preparation:
- Prior to Sprint Planning the Scrum Master forecasts the amount of story points that the team can be expected to complete in the upcoming sprint (I have a process which I use to do this which I cover in a later post).
- Next on a whiteboard the Scrum Master draws a grid with the number of squares being the same as the next sprint’s forecast velocity. Each of the squares represents one story point and should be drawn to be large enough to hold a sticky note. This is the Story Grid.
- The Scrum Master then obtains a list of proposed stories for the sprint from the Product Owner or plucks the first N prioritised stories from the Product Backlog.
- Finally for each proposed story a sticky note is created containing the story’s name. These notes should be placed next to the Story Grid listed in priority order.
- The highest priority story is selected and estimated as normal. My team utilise Planning Poker for this.
- The Scrum Master writes the estimated story point value onto the sticky note.
- The Scrum Master then places the story’s sticky note onto the first square of the grid.
- If the story was estimated to be more than one Story Point then score out the following squares until a number of squares equalling the Story Point value of the story are blocked out.
- Repeat this exercise for each candidate story in priority order. Newly estimated stories are placed in the next available square. Carry on until the Story Grid’s squares are exhausted.
A Simple Example
Here is an example of the technique in action. In this fictional Sprint Planning session there are 12 story points forecast for the next sprint. In addition there are six prioritised stories labelled stories A-F. Valid story point values for estimation are 1, 2, 3 and 5.
Initially the 12 square Story Grid is empty:
Story A is estimated to take 2 story points. It is placed in the first square and the second square is also scored out. Two story points have been consumed on the grid.
Story B is then estimated to take 3 story points. The grid now looks as follows with five story points consumed.
Next comes Story C which is estimated to take only one story point. This is placed in the next available square but no other squares are scored out.
Story D is estimated to take five story points and consumes five squares accordingly.
Finally Story E is estimated to take one story point and is placed on the grid to consume the final square.
The team have now estimated enough work to fill the forecast velocity for the next sprint. There is no capacity for Story F. It simply won’t fit if Stories A-E are to be completed too.
That was a very simple and idealised example. Next I will discuss how the Story Grid operates with less neat examples.
Away From the Ideal
In real world Sprint Planning the first N stories will not necessarily fit neatly into the forecast team capacity. Even if they do there may be other lesser priority stories waiting in the wings that the Product owner is keen to see in the next sprint. This was the case in the example above with Story F. The idea is to plan until the squares or full. If any stories overflow the grid and/or any stories are still to be estimated which do not fit then the Product Owner has a choice.
The Product Owner must still respect the team’s estimates. However, they can decide to pull items from the grid (and therefore the sprint) in place of other stories. This is why noting story point values on the sticky notes is important – the final steps of the Sprint Planning session may involve moving stories in and out of the Story Grid to get the optimal fit that suits the Product Owner. There is nothing wrong with this provided the team agree that the chosen order is still technically feasible. The Story Grid is still serving a useful purpose here as it can be used to visualise the new sprint make up. Finally once the Product Owner is happy with the selection of stories and the team agree that the order is practical the stories can transferred to the Sprint Board.
The most attractive thing about the Story Grid technique is that there is a up-to-date visual representation of the planning session’s progress which is available to everyone as the session progresses. It is clear to the Scrum Master, team and, most importantly, the Product Owner how close the team is to capacity after each story’s estimation. I really like it as a Scrum Master because I no longer have to separately maintain and communicate how close the team is to capacity. The Story Grid has become an integral part of the process. This allows me to focus my mind on everything else that is going on in the session and therefore speeds planning. Finally it is simple so everyone tends to get the idea quickly.
One final practical point when it comes to Story Grids. You will very quickly become tired of drawing them. For this I offer up a practical tip which I received from the ScrumMaster of my first Scrum team six years ago: electrical tape can be very useful as a Scrum Master. You never need to redraw and it can’t accidentally get onto your hands when placing notes like you can with whiteboard ink. As you can see from this picture of my team’s last Sprint Planning session I should really get around to buying more tape to fill in the verticals.