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 on the table
- Put two flip-chart papers on the table
- Each participant should have one flip-chart marker

Instructions:

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

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

- While team is preparing sketch the facilitator prepares a table to measure remaining backlog size, velocity and estimated time to complete each minute.
- Facilitator than explains how to estimate figures in relative story points 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 paining all the figures and write this numbers into the table
- Facilitator explains that the team will be working in iterations of 1 minute and the goal is to produce as many figures as it possible. The Definition of Done – ideally painted (whithout white gaps) figures. 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. Facilitator asks to re-estimate partially done items and calculate velocity based on accepted work
- Step 2. Facilitator gives 3 minutes to plan next iteration and introduces new rule, bigger figures can be split into smaller 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 flip-chart with table

Repeat steps 1-4 until teams complete the project

Learning 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
- 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 fragments 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!

3 Responses to "Paint The Story Point"

Leave a Reply:

Discuss

- Chris Deniaud on (Français) Jeu des rôles et des responsabilités de Scrum
- Cathy on Judgement Juggler
- Mike Burns on Judgement Juggler
- Cathy on Judgement Juggler
- Anja Stiedl on Scrum Card Game

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

5(1 vote cast)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.

5(0 votes cast)Slava – Thank you for the clarifications. Hope to try this game sometime soon.

Regards

5(0 votes cast)