Planning Poker Review

Articles
By Ashley Parsons, Test-Direct Ltd | 13 October 2015

“Having provided the test consultancy which assisted on introducing an iterative, quicker to market SDLC at a software as a service provider, it was imperative we found the right estimation tool to drive the delivery quality forward. Due to the size of the organisation, estimation had previously been done by the product owner/lead developer and projects were determined by these estimates. This led to a lot of over promising of deliveries to their clients and a lot of additional working hours to get deliveries out on time. I had come across poker planning through DSDM a year or so ago and thought this was the perfect opportunity to try it out.

 

For each iteration, we had shortlisted a number of user stories based on the priority v risk approach from our backlog. User story management was being performed using Jira Agile and all members of the project team had access to this in advance of the poker planning session. This allowed for them to review the user stories and prepare for the poker planning session in advance. As Chair, I decided that we would progress through the user stories on a priority basis, with each high priority user story being followed by any dependent low priority user stories before progressing to the next high priority story.

As the company were relatively new to both user stories and the poker planning the initial poker session drove out a few improvements in the process itself, as well as being useful as an estimation tool and knowledge sharing exercise. User stories, being too ambiguous once you got into them or too technical for other project members to really understand the implications of, were a contributing factor to the coffee cup, “I need a break” card being played at least twice!!

We agreed in advance that the numbers on the cards would represent days to complete the whole user story from development through to deployment and I selected the first user story. After I had read the story aloud, all 6 members of the assembled group drew an estimate card from their hand and placed it face down on the table. Once all cards had been placed face down we revealed the estimates at the same time. 

Unfortunately, the first high priority user story was quite ambiguous so the following debate, discussing each project members’ opinions took some time. Thoughts of how long it would take to develop, from the view point of 6 different people at varying levels of understanding and knowledge of the product, followed by a similar debate about the testing effort filled the air. 

After this we decided to focus mainly on the outliers (highest and lowest estimates), as is DSDM best practice for poker planning, and this helped reduce the length of discussion but not detract from the debate. On hearing all of the arguments for the estimation values provided at first the attempt, and replaying our hands, the achievement in gaining that first consensus was very satisfying. It was also a huge step forward for the client.

The standard of the user stories was improved after this first poker planning session. Taking on board the requirements for success from each team member, a template for a fit for all user story summary using the INVEST mnemonic was created. This in turn increased the quality of the release from iteration scope set by the product owner through to deployment into production by the operations team. 

Poker planning sessions do require some time and a strong Chair to keep everyone on track, but if you can afford to invest the time the benefits provided by this technique are worth it.

Ashley Parsons

Test-Direct Ltd