Monday, October 28, 2013

Top tips for Planning Poker

Planning Poker is a simple exercise that delivers outstanding results when performed well. It can quickly lead the team to a shared understanding of the work and an accurate estimate of the size of the work. However I often see it performed sub optimally, leading to waste, inaccurate estimates, misunderstanding and division within the team.

These are my Top Tips for performing Planning Poker in an efficient, effective and fun manner.


Bring Reference Stories

Bring a range of Reference User Stories on index cards to your estimation session. I find that a range of sizes and types of work helps immensely when we are sizing. I recommend that you have between 3 to 10 Reference Stories, in the size range of 1 Story Points to 8 or even 13 Story Points. The reference story index cards can just have the story title written on them (provided the team is well aware of what the story entails).


Reference user stories

Bringing these reference stories serves two purposes. 1. There is no need to recall the Reference Stories from memory, they are right there in front of you. This makes the process of sizing stories easier and faster. 2. It stops ‘size creep’ / ‘story point inflation’, which unintentionally affects some teams.


Involve Everyone

Everyone should display an estimate each round. We do not want the situation where Developers put out a ‘?’ card each time there is a testing focused story and vis-versa.

But how can Testers size Development work you ask? By using Relative Estimation along with asking some probing questions, is the answer. The questions that we need to train the team members to ask, highlight the differences of the Un-sized Story to the Reference Stories. 

Some sample probing questions:

  • Testers can ask: How many components does it affect? How many components were affected in the reference story?
  • Testers can ask: How much development work is there per component, compared to this reference story? 
  • Developers can ask: Do we need to test it on multiple platforms, like we did for this reference story?
  • Developers can ask: Are there more functional areas to tests than this reference story?


With this information out on the table, everyone should have enough information to compare the Un-sized Story to the Reference Stories and hence select a Relative Estimate. This is one the key reasons that Planning Poker works in a cross functional team.


Talk about Complexity, Effort & Doubt

Story Points are made up of complexity, effort,& doubt, with Complexity being the most important aspect. Everyone in the team needs to understands what these all mean and how it relates to their work.

Talk about:

  • More/less complexity (more interactions between components, technical debt that makes it harder to make changes, difficult algorithms, availability of assistance from an expert in the area, availability of documentation that explains how it all works, etc.)
  • More/less effort (extra tasks, extra components to work on, less test cases to create, ability to reuse existing work, available of a tool that automates part of the work, etc.)
  • More/less doubt (lack of tests, uncertainty regarding the current design, unclear expectations from the Product Owner, new technology, not sure if the documentation covers it, etc.)



Don’t talk about numbers

Don’t let team members talk about changing your estimate. E.g.  'I will go down to a 5.' 'Ok, ok it's a 2.', ‘Alright I’ll go up’.

This results in or is the result of peer pressure. ‘Story Points are only one third of the reason for estimating’, peer pressure prevents the team from gaining the other two thirds worth of benefits. 

Also try to avoid talking about how much time it will take to do things. ‘Story Points do not equate to Time’, so we should minimise our mention of time.

Instead of talking about numbers, get the team to focus on Effort, Complexity & Doubt, and then re-vote.


Choose the Majority answer

Create a team rule that ‘When there is a lack of consistency in estimates after two rounds of estimation; the estimate which the majority of team members have chosen is selected as the estimate.’ 

Picking the majority answer instead of picking the highest answer (or the lowest) ensures that the team’s estimates will average out over the long term. Always picking the highest estimate will inflate the team’s estimates, and lead to less predictability.


Example voting results, showing to choose the majority, not to average the results
In the above example, with 4 votes to 3 votes, the team would choose 5 as their estimate.

Use estimation to confirm shared understanding

Watch out for stalled/circular discussions and call for the team to estimate. 

Sometimes you will find that the team all throws out the same estimate! When they do you can move on. Even though the conversation was going around in circles the team had a similar idea of the size of the work. Which means you can sort out the details in the sprint, instead of trying to sort it out in your estimation session.

If some team members do throw out different estimates; then you need to head back to the discussion to try and clear it up. The good news is that the attempt at sizing will have only taken a minute or so.


Combined result

Once you and your team are practiced in how to run an effective Planning Poker session; it should be fast, accurate and fun.

Do you have any other tips that have lead your team towards great Planning Poker sessions?


Interested in more tips?


Interested in estimation?



Training available in South East QLD, Australia



If this article was interesting to you, then your team would likely benefit from face to face training on Agile Estimation. I run a one-hour Agile Estimation training session, that is highly interactive, immensely fun and teaches the foundation of agile estimation along with how to effectively run Planning Poker as well as Fast Estimation. Please contact me to set up a training session for your team: andrewrusling@hotmail.com



Saturday, October 19, 2013

Top Tips for Project Retrospectives

Project Retrospectives tend to be high stakes, emotionally charged, cross teams events, with managers in attendance. This all adds up to an environment that is not ‘Safe to Fail’ as you would expect in a typical Sprint Retrospective. While my Top Tips for Sprint Retrospectives can still be applied to Project Retrospectives; the several significant differences between these Retrospectives, means a different style of approach is needed.

Project Retrospectives are useful when a project spans multiple teams and multiple sprints. During the project I would expect that each team would hold a Sprint Retrospective every Sprint. The Project Retrospective is an additional ceremony that occurs after the project is completed. This could also apply to Release Retrospectives, i.e. a Retrospective for all of the agile teams involved in a multiple sprint release.


What follows are my top tips for running a successful Project Retrospective. i.e. A Retrospective that allows the real issues to be identified and action taken to resolve them.


Tip: Choose the attendees wisely

The attendees that you invite will have a significant bearing on the issues that are identified and importantly on how successfully those issues will be addressed. I recommend you invite:
Representatives from all teams involved in the project.
Representatives from all disciplines involved in the project (e.g. product owner, leaders, project managers, business analysts, developers, testers, designers, architects, support). 
People who will speak honestly in front of management.
Stakeholders/Management that will hear the issues first hand; then be available to own and resolve those issues. This is crucial to a Retrospective leading to real change.
As few people as possible, certainly less then 15. To help with this mix up the discipline you invite from the separate agile teams. e.g. Developer from one team, tester from another, business analyst from a third.


Tip: Get all attendees to prepare ahead of the meeting 

About a week ahead of the Retrospective, hand out post it notes to all attendees and ask them to pre-write their thoughts: what went well, what went poorly, what can we improve? This will save a lot of time in the meeting.

You can also get prepared yourself. I recommend researching a timeline of important events from the life of the project (e.g. Customer signs contract, First Release, huge technical issue first identified, original targeted delivery date that was missed, Final Release). Just prior to the start of the meeting you can draw up this timeline on the whiteboard.

Also just prior to the start of the meeting you can write the objective of the meeting up on the whiteboard. Such as ‘Objective: Assign Owners to the Key Issues we identify.’  This will prove useful when discussions in the meeting start to get off track. You can point to the written objective and ask if the current discussion is helping us to achieve our goal?


Tip: Schedule it promptly after the Project ends

Timing is crucial. It should not be immediately after the project ends, because some peoples feelings will be raw. It should definitely be within one month of the project end, so that it is still fresh enough in everyone’s memory.


Tip: Use a structured yet simple agenda

The agenda that I recommend is:
Facilitator provide an introduction [1 minute]
Gain shared acceptance of the meeting objective [2 minutes]
Attendees to post their ideas on the timeline & cluster them as appropriate [5 minutes]
Facilitator lead discussion of the clusters in priority order (large clusters first) [75 minutes]
Facilitator summarise the issues and owners [5 minutes]


Tip: Focus the meeting on assigning owners to the key issues

While facilitating the meeting you should try to focus the discussions on 
Bringing out the issues; and moving towards the root cause. 
Agreeing which issues are the priority issues to be addressed.
Getting agreement on who in the room should own each issue and hence resolve it.


Tip: Follow up after the meeting

Send the list of agreed issues & agreed owners to all of the attendees. You may want to consider posting this in a public location such as a Wiki.

The real key is regularly following up the owner of each issue. You need to ensure that they are working on resolving the issues. Otherwise the whole exercise will have been an expensive whinge-fest. 

Retrospectives are meant to lead to Real Change, you can make it happen.


Interested in more tips?





Photo by: Rafael Anderson Gonzales Mendoza