Agile Metrics Workshop

This workshop was conceived independently, although it is noted that it does have a strong resemblance to a similar exercise used by Rowan Bunning in his CSM / CSPO class although his variation uses unknown scenarios for each sprint to challenge the attendees. This workshop only focusses on completion with no disruptive scenarios.

Learning Objective

The purpose of this game is to provide the attendees with the knowledge of how the metrics work within a Scrum project through simulated game play.

This workshop is intended to provide participants with some practical experience with Agile metrics that can be useful for release planning and to help teams to focus on what is important.

In this workshop participants will learn:

• How to estimate and size product backlog items
• How to measure and plot progress towards release objectives, and the likely decisions that Product Owners can make to help them
• How to measure and plot progress towards iteration objectives, and the likely decisions that teams can make to help them

Timings

• The game needs to run for 1 hour to give the teams enough time to simulate a 5 sprint project.

Materials

The equipment needed includes:

• Flip chart paper - enough for each team of ones and twos to have 2 sheets of flip chart paper each
• Whiteboard
• Whiteboard markers - enough for all of the delegates to use and of varying colours
• Felt tip pens of assorted colours
• Index card of various sizes and colours
• Dice - enough for pairs of attendees to be able to throw two dice
• Blue tac or similar to fix the user stories to the flip chart paper
• Post it notes
• Release and Sprint burn down charts

Preparation

Up on the whiteboard draw out the Planning Poker numbers with a reference to the dice throw to select the correct estimation number. In addition draw a brief outline of the product backlog and sprint backlog that the teams are to create on their flip chart paper.

Useful Instructions

Estimating Story Points

To assist with the prioritisation and release planning activities, items can be estimated with the following method:

1. Estimate an item with user story points by throwing two dice to map to the corresponding Planning Poker number
2. Write the resulting Planning Poker number on the index card and repeat for the remainder of the items in the backlog

score	2	3	4	5	6	7	8	9	10	11	12
Corresponding Story Points	0	0.5	1	2	3	5	8	13	20	40	100

Estimating Business Value

The value placed upon an item by the Product Owner can help with the prioritisation of the items relative to each other, which can also influence the release planning of a product. The below method simulates the business value estimation for the game.

1. Assign a business value to the user story by simply throwing a die and writing the resulting number, 1 to 6, on the index card

Re-Estimating Part Done Items

1. Occasionally there may be Items that are only part done from the previous sprint and will need to be re-estimated using the method above.

Splitting Items

Sometimes the items can be too large to complete within a sprint and so need to be broken down into something more manageable. The below method indicates how this can be done for large items.

1. To split an item simply replace it with 2 or more index cards and then decide how many story points to apportion to them.
2. The existing business value that was originally used for the original item should then be transferred to the replacement items, as the business value placed on this item of work will not have changed

Game Play

Setting Up The Product Backlog

1. Arrange everyone into pairs
2. To start with distribute 8 index cards to the teams
3. Estimate the items with user story points using the above table to map dice throw to story points
4. Ask the teams to write the story points on the index cards with one of the marker pens
5. Assign a business value to the stories
6. Prioritise the product backlogs by arranging the index cards in descending order of business value
7. Ask the teams to create their own product backlog boards on flip chart paper as per the diagram on your whiteboard
8. And add the index cards onto their respective product backlogs, fixing with blue tack or similar

Sprint Planning

1. Ask the teams to create their sprint backlogs on separate flip chart paper as per the diagram on the whiteboard with appropriate sprint burndow charts for a 5 day sprint
2. For any part done items from previous sprints, re-estimate the story point estimates
3. Using the velocity from previous sprints to determine how many story points to forecast, each team should decide how many items to place on their sprint backlog with the remainder being placed onto the product backlog in order

Daily Scrum

1. To simulate the daily standup ask the teams to throw two dice for each day to get a daily effort burndown
2. Ask the teams to decide which items to burndown on the sprint backlog and mark them as being done
3. The teams should then update the index cards with the decremented story point estimates and update their respective sprint burndown charts at the end of each day
4. Continue to simulate the daily scrum and the burndown of work for 5 days until the end of the sprint is reached

Sprint Review

1. Ask the teams to total up the story points done for the sprint on the sprint backlog at the end of the sprint
2. Ask the teams to update their velocity charts with the user story points achieved and mark the completed index cards as done
3. Create 2 new index cards, estimating them for story points and business value in the same method indicated above to simulate feedback and new ideas
4. Factor in the new items into the product backlog according to the estimated business value

Release planning

1. At the end of the sprint ask the teams to incorporate release planning based upon their exhibited velocity and release burndown in previous sprints by refactoring their product backlog to reflect how many items can be done in the maximum number of sprints for the project. N.B. 5 sprints may be adequate for the lessons of the game
2. If releases are decided upon during release planning, ask the teams to indicate which items belong to which release by adding a symbol to the index cards
3. Ask the teams to then create and update a release burndown chart on the product backlog with the story points achieved in the previous sprint

Next Iteration

1. Go back to sprint planning and run through the steps again until 5 sprints have been completed.

Closing

1. To close the session draw a quick mind map on the white board and canvass from the teams what observations they had with respect to release planning, velocity and the burndown charts.