The Scrum Value Simulation – Condensed

While attending training by Jeff Sutherland I had the opportunity to try Joe Little’s Scrum Penny Game which I believe did a good of showing the importance of small batches. Recently I was tasked with training a new Sprint team and was given 1 day to do it. I needed to come up with quick interactive examples of Lean principles. While searching the great cloud of information I found 2 good examples.

• Peter Stevens blog “Scrum Breakfast” had a great game under the heading of “The Scrum Value Simulation”
• Karen Greaves blog has a modified version under the heading of “The Scrum Penny Game – a modification”

I created a variant of the Scrum Value Simulation that compressed the steps:

Supplies Needed:

• 20 pennies per group
• Team of 4 coin flippers
• 1 PO that times how long it takes all 4 coin flippers to get through their batch of coins.
• Start the clock on the first coin flip by the first coin flipper
• Stop the clock on the last coin flip of the last coin flipper
• 1 time recorder (PO’s Boss)

Game Setup:

• Have the coin flippers stand around a table
• Put 20 pennies in front of the first coin flipper
• PO stands by with a stop watch to time how long it takes for all the coins to be flipped by all 4 coin flippers.
• PO’s Boss stands at the Whiteboard ready to record the time from the PO after each round

Game Play:

• Round 1: Baseline (batch size 20)
• Team may only use their left hand
• Each person flips the batch of 20 pennies
• When done with entire batch, pass to next person 
• Round 2: Reduce batch size to 5
• Team may only use their left hand
• Each person flips batches of 5 pennies and then passes the batch to next person before starting the next batch
• Keep flipping and passing until done
• Round 3: Remove impediment (batch size still 5)
• Team can use both hands
• Each person flips batches of 5 pennies and then passes the batch to next person before starting the next batch
• Keep flipping and passing until done
• Round 4: Self organize
• Each table creates their own rules to maximize penny flow/throughput in least amount of time
• Possibly making batch size 1?

Game Results:

Round	Time Worked
1	1 minute 37 seconds
2	1 minutes 5 seconds
3	36 seconds
4	23 seconds

Lessons Learned:

No one wears a watch anymore. Luckily everyone has a cell phone and most have a stop watch feature.

• Smaller Batches (shorter iterations)
• Smaller batches mean more value is delivered and workers can spend more time working as they are working concurrently.
• The first value is delivered earlier to the customer
• Removing Impediments
• Removing impediments mean that more value is delivered without the team working any longer. They are just more effective.
• Rugby approach over Relay Race
• Self organization, it is better to go the distance passing the ball back and forth

I was surprised that the team “really” liked the game and was quick to grasp the principles, especially the principle of small batches.

Scrum Thoughts

Scrum allows a team to continually improve upon the way they work on a constant basis. Since Sprints are time boxed to a specific iteration the team can count on each sprint end to review, improve and hone their processes.

Sprint Retrospective

·         After the Sprint Review meeting the team will get together and answer 3 questions:

o   What went well?

o   What went poorly?

o   What can be improved?

·         As we are an Agile team using an Agile process we need to continually improve our process and this can only be done if reflect on our process.

Sprint Review

At Sprint end the team shows their work to the Product Owner in the Sprint Review meeting. In the meeting the team presents what it accomplished during the sprint. This is typically in the form of a demo where the whole team participates. The Product Owner has the final authority to determine if a Story is Done. If any part of the work is deemed Not Done a Story is created to represent the work that was not accomplished, but most of the time when this happens it is usually a small task that can be moved to the next sprint and it considered when committing to the next batch of work in that sprint.

Sprint Status Meeting

Sprint Status – The Daily Standup/Scrum meeting:

Each day of the Sprint the team gets together for a time boxed meeting of 15 minutes that we call the standup meeting. The team stands to ensure the meeting is quick. The purpose of the meeting is to keep the team up to date and follows the below process:

·         Everyone answers 3 questions

o   What did you do yesterday?

o   What will you do today?

o   Is anything blocking/impeding you?

·         We usually also take this time to move the work items to their true state in the Task Board.

The tasks need to be updated daily to allow the team to know where they are and how they are doing against their commit.

This Status of the Task are usually represented through a Sprint Burn down chart show below:

Sprint Planning Meeting

Sprint Planning or the Sprint Kickoff meeting:

At the beginning of each Sprint the 3 roles of Scrum get together to plan and select the work to be accomplished in the Sprint Iteration. I like the Product Owner to come up with a Goal for the Sprint which represents at a high level how they see this Sprint helping our customers. Below is an example of a Sprint Goal:

Support personalization of our product

Add new Shopping Cart to the site

We then move onto the planning phase:

·         The Sprint Team determines their available hours for the sprint

·         The Sprint Team reviews Backlog and select user stories that can be accomplished in the Sprint Iteration.

o   The work selected is chosen in priority order from the Product Backlog

o   The work to be done is clearly understood by all. If it is not the team asks the Product Owner for clarification

o   The team will review estimates and confirm they are correct to ensure the work fits within the Sprint Iteration

·         The Sprint Team then Commits to the selected work which is represented in the Sprint Backlog

·         Once the work has been agreed upon and Committed to the team then breaks the work down into Tasks where they put Estimates against each task.

The Sprint

·         Time-boxed iteration with fixed deliverables

o   No changes to deliverables once a team commits

§  Negotiations, maintenance, etc. are still up to the team.

o   No changes to sprint duration, sprint ends on planned date regardless of completion state

·         Sprint activities are end to end

o   Research, Analysis, Design, Code and Test

o   Some Planning / design can be done in the current sprint through Spikes for the next sprint.

§  I use this step to continually clarify the backlog