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!
VN:F [1.9.16_1159]
Rate This
please wait...
Rating: 4.2/5 (5 votes cast)
Paint The Story PointЗакрась Стори Поинт, 4.2 out of 5 based on 5 ratings
[:en]Written by: [:ru]Написано: Slava Moskalenko[:en]on [:ru] June 1, 2016.on October 29, 2017.
4 Responses to "Paint The Story PointЗакрась Стори Поинт"
JayashreeJune 17, 2016 at 1:47 am
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
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.
VN:F [1.9.16_1159]
please wait...
Rating: 5.0/5 (1 vote cast)
Jayashree NagarajAugust 24, 2016 at 2:14 am
Slava – Thank you for the clarifications. Hope to try this game sometime soon.
Regards
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
[…] demonstrate effectiveness of the Story Points you can try out the Paint the Story Point […]