Planning Poker: Cards Versus Smartphone Apps

My team have been using Planning Poker in our sprint planning for quite a while now. I like Planning Poker because it is quick and it works. I have a couple of card decks I’ve picked up on training and at conferences and even made my own. Recently I decided to run an experiment within the team to utilise smart phone apps rather than cards for our next planning session. I reasoned that perhaps the team, being software developers, may prefer to utilise apps on their flashy phones rather than use boring old cards.

On the face of it the modern smart phone seems ideally suited to Planning Poker. Most people I know have one, they have large bright screens which are usually approximately the same size as a Planning Poker card and, I reasoned, somebody must have written a Planning Poker app for them (and it would probably be free). Quick trips to the Google Play and iTunes stores confirmed that not only had a Planning Poker app been written but that dozens of different apps were available.

Prior to planning I requested that the team go and find a Planning Poker app for their phone for use in the upcoming session. The choice of app was entirely up to them. In the team we have four Android wielding members and one iPhone owner. Here is a list of what app each team member decided to use:

• Planning Poker (by Unboxed Consulting, for Android)
• Planning Poker++, (by Richerd Everett, for Android)
• Scrum Poker Cards (by Artarmin, for Android)
• Bacon Poker Planning (by mmmBacon, for Android)
• iScrum (byValenti Freixanet, for iOS)

Proof of the sheer number of Planning Poker apps available is that everyone picked something different. Choice is certainly not an issue here. My own selection was the simply named “Planning Poker” by Unboxed Consulting. It appealed to me because it was very simple to use and I could customise the set of available card values easily (we use a restricted fibonacci sequence including the values 1/2, 1, 2, 3, 5 and 8).

All of the apps operate in the same fashion. The user starts the app and a screen appears with a grid of all possible card values, they select one and a representation of a card with the chosen value appears. They can then dismiss the card and return to the grid in preparation for the next round. The advantage of using the apps rather than a deck of cards appeared to me to be slight. However, I wondered if the novelty value and convenience factor of the apps would allow them to usurp the cards. It would be up to the team to decide.

The session went as quickly as usual with no technical malfunctions. Once my phone did not register my making a selection and I initially showed the selection grid as my estimate. That wouldn’t happen with a real card deck but, then again, I was in too much of a hurry. All of the app’s representations of card values were legible although I did find the Bacon Planning Poker’s use of rashers of bacon to make up numbers to be a little bit too weird. Then again I’m not a big fan of bacon.

With the session done I wanted to know whether or not using the apps would be a permanent feature of our planning. I asked the team to dot vote. What was their preference: apps or cards?

The dots went up rapidly with not a hint of hesitation from anyone. The results were unanimous:

Click to enlarge

So cards are here to stay in my team. Smartphone apps are great for many things but are no match for real Planning Poker cards.

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.

Preparation

The idea is simple. First comes the preparation:

1. 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).
2. 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.
3. 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.
4. 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.

Execution

During planning:

1. The highest priority story is selected and estimated as normal. My team utilise Planning Poker for this.
2. The Scrum Master writes the estimated story point value onto the sticky note.
3. The Scrum Master then places the story’s sticky note onto the first square of the grid.
4. 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.
5. 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:

Click to Enlarge

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.

Click to Enlarge

Story B is then estimated to take 3 story points. The grid now looks as follows with five story points consumed.

Click to Enlarge

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.

Click to Enlarge

Story D is estimated to take five story points and consumes five squares accordingly.

Click to Enlarge

Finally Story E is estimated to take one story point and is placed on the grid to consume the final square.

Click to Enlarge

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 Advantages

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.

Click to Enlarge

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.