Purpose

- Demonstrate how planning and estimating with relative story points can benefit business to be more agile and transparent

Timing

Entire game usually take 60 minutes to run including debrief.

- 15 minutes – estimation
- 35 minutes – complete painting (each painiting iteration is 1 minute)
- 10 minutes – debrief

Materials and setup:

- Teams should consist of 4-5 people
- Team should work at the table
- Put two flip-chart papers on the table
- Each participant should have one flip-chart marker

Instructions:

- Prepare flip-chart poster with figures of the different sizes and shapes

- Each team should copy paste original sketch onto its own flip-chart poster

- While team is copying its own poster the facilitator prepares a table to measure remaining backlog size, velocity and estimated time to complete.
- Facilitator explains how to estimate figures in relation to each other using fibonacci sequence and ask teams to estimate all figures in relative story points
- Facilitator asks to calculate the sum of all story points and write it in the table.

- Facilitator gives 1-2 minutes to provide initial estimates of how much time it will take for entire team to complete colouring all the figures and write this number into the table
- Facilitator explains that the team will be working in iterations of 1 minute and the goal is to colour as many figures as it possible. The Definition of Done – it should be ideally painted out (whithout white gaps). It makes sense to start painting from the smallest figures in order to get the best possible velocity
- Step 1. Facilitator run first iteration and accept only ideally painted figures. Facilitator asks to re-estimate partially done items and calculate velocity based only on accepted work
- Step 2. Facilitator gives 3 minutes to plan next iteration and introduces new rule, bigger figures can be split into smaller parts and can be delivered incrementally, however the fragments should be re-estimated in story points and initial estimate on big figure should be disregarded

- Step 3. Teams should update remaining story points in the backlog and facilitator updates the table. Update time-to-complete dividing remaining story points by last velocity and compare with initial estimate
- Step 4. Teams have another minute to continue painting. Facilitator obsereves what is going on and capture obesrvations into poster with table

Repeat steps 1-4 until teams complete the project

Learning Points:

- Discuss why having identical initial sketches between the teams we still have so different estimates in relative story points
- Discuss why initial estimates of time to complete are so different (usually one team estimate time to complete as 20 minutes, other team as 10 minutes). Discuss how customer can rely on initial time forecast if teams are providing so different values
- After first iteration, if velocity is low because of many undone items, discuss why it is so bad in agile development to have many in progress and few completed, how this impacts transparency and ability to use velocity for forecasting
- Demonstrate how to create release burn-down chart from the table
- Discuss why it is good when the velocity is changing over the time and how to teach stakeholders to accept this as the reality
- Discuss all your observations
- Discuss why we are so bad in the forecasts (usually teams more pessimistic and provides two times bigger estimate, average team complete paininting in 6 one minute iterations)
- Debrief lessons learned and ask people to tell their observations and the benefits of this estimation approach
- Ensure that the participants understood the value of relative story points and how to use it for measuring velocity and forecasting time to complete
- Investigate the value of splitting bigger figures into smaller parts and incremental development of the bigger epics
- Explore the different strategies of the team work and how that improved after each iteration and the value of iterative-incremental development
- Ask everyone to celebrate and have fun!

Hi there – Thank you. I want to try this with my team who are very skeptical of using SPE for planning releases. Some questions for you.

Can you give me some insight into discussions around these points?

– After team estimated initial sum of all story points the difference can be two times. Discuss why having two identical sketches we have so different estimates in relative story points

– Discuss why initial estimates of time to complete are so different (usually one team estimate time to complete as 20 minutes, other team as 10 minutes). Discuss how customer can rely on initial time forecast if teams are providing so different values

– After first iteration if velocity is low because of many undone items. Discuss why it is so harmfull in agile development, how this impacts transparency and inability to use velocity to forecast time-to-complete

Hi, Jayashree,

thank you for feedback. Let me add more details

1) After team estimated initial sum of all story points the difference can be two times. Discuss why having two identical sketches we have so different estimates in relative story points

Learning point is that it is OK that different teams may have different estimates in relative story points. But velocity also will be different. Velocity just shows the burning rate of the RSP which is useful for product release forecasting.

2) Discuss why initial estimates of time to complete are so different (usually one team estimate time to complete as 20 minutes, other team as 10 minutes). Discuss how customer can rely on initial time forecast if teams are providing so different values

I hope that you have a group of 6-8 people which you can split into 2 sub-groups. Very often I have two different estimates from each group. The first group tells me they will complete painting in 10 minutes, second one estimate in 20 minutes ))) Just discuss with people why we have so different estimates, given that the both team have identical and relatively simple task comparing to programming.

The learning point should be that we cannot rely on the initial estimates and it should be re-visited every Sprint for entire Product Backlog. And every 24 hours for tasks in Sprint Backlog.

3) After first iteration if velocity is low because of many undone items. Discuss why it is so harmfull in agile development, how this impacts transparency and inability to use velocity to forecast time-to-complete

So many times I see how people are doing in first iteration. Usually they start to “own” the figure and in the end none is done ))) The velocity is ZERO. And because of that I cannot use Velocity to forecast task completion. The expected insight – people should focus on Sprint Goal and collaborate to deliver maximum value for customer instead of “owning” their personal User Story.

Slava – Thank you for the clarifications. Hope to try this game sometime soon.

Regards