Planning poker

This fortnight’s discussion at the London Agile discussion group was all about planning poker. What is planning poker and who should be included in the process? Should the Product Owner, ScrumMaster, analyst take part in sizing? Do you size development and testing separately?

The session started with a brief description on what planning poker is and when you use it.

Planning Poker is an agile estimating and planning technique that is consensus based. To start a poker planning session, the product owner or customer reads a agile user story or describes a feature to the estimators. 

Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100, which is the sequence we recommend. The values represent the number of story points, ideal days, or other units in which the team estimates.

The estimators discuss the feature, asking questions of the product owner as needed. When the feature has been fully discussed, each estimator privately selects one card to represent his or her estimate. All cards are then revealed at the same time.

If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After further discussion, each estimator reselects an estimate card, and all cards are again revealed at the same time.

The poker planning process is repeated until consensus is achieved or until the estimators decide that agile estimating and planning of a particular item needs to be deferred until additional information can be acquired.

Then people stated what topics they wanted to cover which was captured and grouped using post it notes. These suggestions included:

  • When should it be used? Alternative methods

This was quite interesting as for me I would only use planning poker in an estimation session, getting enough stories for the next sprint. Not all the stories in the backlog will be delivered so why would you spend time sizing them. To follow the just in time theory, make sure you have enough stories sized and agreed on that will keep the team busy for the sprint. Potentially if the velocity increases have some stories that have been analysed and have the acceptance criteria ready ready so another sizing session can be run during the sprint.

From experience if you size too many stories that are not developed in the sprint, when the developers come to doing them a few weeks later the memory needs to be refreshed exactly what was involved, so if you try and do too much upfront this adds delays later on in the process.

Alternative methods included sizing by functional tasks, though I feel this will take more time and this is meant to be an estimation that you don’t spend too long or too much energy on. It’s a way to create enough work for the iteration. Some teams don’t estimate using planning poker but use BDD in the planning session, writing their tests and from this work out how many stories they can do.

  • Who should be involved?

Interesting to see what people do! The consensus was to have the whole team there, as in agile teams this is normally less than 10 people. This session is useful to have the team in as the Product Owner of the Business Analyst presents the story and is there to answer any questions so everyone hears the same information.

Some teams just have the team delivering sizing and others included the PO, but when they average out the numbers the non-delivery peoples’ numbers are not included. The advantage of getting the PO to size is that is they size low and the developers/testers size high it can highlight a difference in understanding of the exact capability the PO needs.

It is useful to have people in there that have testing knowledge as sometimes a change that is very simple can have a massive impact on the existing system so a lot of regression testing will need to be done.

There is no ‘correct’ solution but try different things and see what works for your team.

  • When do you send a user story back – what is too big?

The majority said that if it were 8 points or higher they would push the story back to the PO to split it further as higher than 8 brings in more uncertainty of exactly what is needed so if it can be split people will get a better understanding. Though it was highlighted to remember INVEST and that the stories need to be independent when they are split into smaller pieces.

  • Resizing? When do you lock a story down?

When a story enters the sprint the size is locked down. During planning poker you may want to resize after the people with the highest and lowest scores have explained why they have voted this way.

  • For the Release plan do you size the whole backlog?

It was highlighted that managers like knowing how long things will take. For the backlog majority of places size this using T-shirt sizes to give a basic estimation of time. In Agile you are always learning and adapting to needs so what is in your backlog and what is delivered is rarely the same so sizing a project using requirements is hard. A project could be time boxed, delivering the prioritised items first and then see where it is at the end of the time box.

There was a good selection of different experiences with the people involved in the room which allowed a good discussion. To me there is no book way to do these things, each team is different and you need to be flexible to allow for this.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s