Exercise: Estimating User Stories

This exercise demonstrates task size estimation using ‘story points.’ A story point is a unit-less measure of size and complexity for a story. More important than the estimate is the discussion the group has about the story. This activity helps a group understand what tasks and proposed solutions might mean/be before attempting to implement them.

Objectives
Understand the ‘planning poker’ technique for task/story estimation for high tech development project and to obtain useful estimates for (iteration) planning.

Prerequisites
Familiarisation with ‘user stories’ and the ‘story card’ method for capturing goal driven requirements.
Planning poker cards or index cards with range of numbers (?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, & coffee)

Instructions
Budget up to 45 minutes to run the whole exercise (for a class size of ~50). Arrange class into groups from 4 to 7 people.

1. Allocate 1” for everyone to read through the ‘local’ rules for planning poker below.
2. Discuss planning poker rules to clarify understanding.
3. Allocate 2” for everyone to read the scenario carefully (don’t make personal estimates yet).
4. 25” for planning poker rounds.
5. 15” for debriefing discussion.

(Local) Rules for Planning Poker; adapted from (Cohn, 2006)

1. The dealer picks up the next story and asks: “Ok, how many story points will this story take?”
2. Team members think about the story and come up their own estimates. Nobody speaks the estimate just yet.
3. Members place a card from their decks face down on the table, with a value equal to or close to their estimate.
4. When everyone’s card is on the table turn the cards over at the same time.
5. Each person explains what he or she thought the story required, maximum of 3 minutes discussion.
6. Taking account of new information the cards are played again (and perhaps again) until rough convergence is achieved or one developer’s proposal and estimate is agreed upon.

Discussion points

• Did you identify duplicate entries?
• How did you handle user stories that did not follow the “As a… I want to… so that…” pattern?
• Were some user stories too ambiguous to estimate?
• How did the teams make sense of the stated requirement?
• Did the teams seek clarification from the product owner?
• How were divergent estimates treated?
• Describe your ‘feelings’ about the process? Fair, political, honest, dominated, contentious, accurate, shared, personalised, ideas, support, attack…
• How did the team arrive at a shared interpretation of the estimated value?
• Did you attach a concrete meaning for the estimate figure? Dimensionless, people, complex-standalone, similar to or like something else, hours, days, small-medium-large, easy-difficult…

Online version

The online version we'll use is courtesy of PlanningPoker.com's basic free account access.

Register at https://play.planningpoker.com/plans and select the free account option

Only one member of the group needs an account. One member of the group sets up the planning poker session. Those invited should not need to register to play.

Enter the following stories:

First a simple test run...

Organise a class night out under Covid

https://play.planningpoker.com/play/game/xItYl4XolMNg93wpjLy39cHOHssGPvYn

Title: Organise a class night out under Covid

Description: As a member of the class I want organise a social event for the whole class that is fun and interactive and accessible so that we (as a class) get to know each other better.

Acceptance Criteria:

It must...

Involve the whole class

Conform with social distance norms

Be fun

Be accessible 

Be interactive

You provide a Wedding Planning Service

The couple wants you to plan and design a whole wedding experience.

How long will it take you to put together a proposal for the following...

• A wedding experience starting on Christmas Eve.
• Options for the perfect venue - a Castle in the West of Ireland.
• With accommodation and board for approximately 200 guests (around 150 arriving from abroad).
• Arranged airport to venue transportation.
• Providing three separate marriage celebration ceremonies running over three consecutive days, each in a different style: European, Asian, South American.
• Concluding with a morning reception on the last day.
• Offering high impact evening entertainment options.
• Provide Media Service and Management (socials, streaming, video, photography).
• Full Security offering.
• Provide optional sports and tourist activities over 3.5 days.
• Arranged airport transportation for departing guests.

Bridge Design Lesson Plans

• A. Five classic bridge designs 
• B. Bridge failures!
• C. Test stuff to destruction!

Title: A. Five classic bridge designs 

Description: As a teacher I want student groups to construct models of the 5 classic bridge designs so that they have practical hands-on experience of design construction challenges.

Acceptance Criteria:

Proposed lessons to be delivered in blocks of 45 mins for a sample group of students (teenagers).

Student group completes lesson for bridge type 1  in 45 mins

Repeat lessons for bridge types 2-5 each taking 45 mins.

Photographic outputs from each lesson.

Title: B. Bridge failures!

Description: As a teacher I want students to test the weight bearing capacity of different bridge designs so that my students will appreciate the applications for different bridge types.

Acceptance Criteria: 

A lesson plan for a 45 min class

Students to generate photographic evidence and scientific data relevant to bridge performance.

Title: C. Test stuff to destruction!

Description: 

As a teacher I want students to evaluate different building materials and relate them to physical design elements  so that my students will appreciate the suitability of material choices for different bridge elements.

Acceptance Criteria: 

Each proposed lesson to be delivered in blocks of 45 mins

Students to create a table of physical characteristics

Students to create a table of load characteristics

Students to create analytical maps of physical demands for bridge design elements

References
Cohn, M. (2006) Agile Estimating and Planning, Upper Saddle River, NJ, Pearson Education.

On imposing a single estimate.

Mike Cohn from Mountain Goat Software posted a reflection on imposing single estimate for a backlog item that will necessarily involve more than one specialism. He wrote:

"During the heat of a Planning Poker session, it can be very tempting to decide to shorten some of the discussion by using multiple estimates instead of a single value. For example, if testers and programmers are having a hard time coming up with a single estimate for the full work, someone may suggest putting “programmer points” and “tester points” on each product backlog item. This is almost always a mistake."

After reading the full post I think the key idea is that you can't really trust composite estimates, made by several contributors, working on what is ostensibly the same job. Any estimate and re-estimate must be down to the judgement of the person who signs up for the item, even though it is implicit that they will necessarily need to involve other specialisms. As I see it estimation shouldn't be a back-door to task atomisation. The correct reading of estimation is that it offers a process of sharing knowledge and, in conjunction with the standup meeting, shared support. Ulimately we want a person who 'takes it on' also takes responsibility to make sure it gets done done, not 3 or 4 people all pointing fingers at the other to blame for a problem.

A link to Mountain Goat Software's estimation notes

Cost+ estimation

Estimation attempts to address the two great unknowns of complex technological systems development:

How much things cost

and

how much things cost!

Q: Why did I write "cost" twice? 
Because I want to highlight that we're interested in more than monetary cost. Cost can be thought of in terms of the resources available or needed, things like the effort (of knowledgable people), resources we already have or can alter (tools, spatial arrangement, environment), and other things we can acquire (more or newer tools, equipment, space, specialist inputs etc). Linked with this is also the idea of "opportunity cost", the hypothetical cost of not doing something as we pursue one goal over another. However the point of this post is to develop the concepts and understandings needed to perform estimation.

For the moment I'll focus on the first "how much things cost"; the second "how much things cost" is the province of the complex technical sale, value perception and price, an entirely specialised domain, skill and art in its own right.

The question here is "how much will it cost to develop? What is the effort? How long will it take? How many people for how long to produce a nominal deliverable (more or less?)?

Accepted wisdom suggests that you make a guess, double it and hope for the best. Why? Novel valuable high tech requirements are by definition unknowns. And estimating how to produce an as yet unknown, unfinished thing is necessarily an art, not a science. But we don't need to leave it there; there are some approaches and practices, that combined, enable us to make informed 'guesstimates' or scientific wild-ass guesses (SWAG) that help us overcome this bind.

For example, if a requirement is very similar to something we have encountered, resolved or done before then, all things being equal, we use the prior experience as a template to estimate the cost of addressing the new requirement.

But as the new requirement strays into the unknown then risk and uncertainty increases and estimates inexact. Yet even here rigour can be applied, knowledge, expertise and judgement employed to suggest effort, cost and timeframe estimates.

"Estimation as practice" relies on the skill, knowledge, resources and contexts of those involved in a situation. Estimations are 'situated' in the same way that other kinds of knowledge work are situated amongst context, history, place and moments in time.

The methods below offer the rigour of organisational processes, from which estimates can be produced (and refined) for planning.

---

The Planning Poker method is a Delphi technique, an approach that harnesses the collective knowledge experience, judgement and wisdom of team members.

---

Constructive Cost Model (COCOMO), currently titled COCOMO II, is a holistic method for estimating software costs and schedules using generalised software design elements as a cost units. In simple terms you start from a figure of one person-month per function point (incorporating specification, design, test, documentation etc), and refine according to the empirical results your team/organisation achieves.  COCOMO II provides three models for estimation/planning:

1. Application composition; applies complexity-weighted costs for objects like screens (with layout, buttons, input, displays), data tables/schema, reports/outputs, components, objects etc. 
2. Early design; combines function point numbers and sizes with personnel attributes.
3. Post-architecture: includes source lines of code (SLOC), function points, current architecture, code use/reuse, and project history data.

---

Exercise: Planning poker scenario

Scenario: You are a member of a joint committee of Engineers Ireland and the Irish Software Association tasked with developing instructional documentation, training videos and conducting an outreach programme for secondary schools.
Your goal: Excite students about a career in bridge design!
The volunteers are ‘sizing’ the effort needed to deliver educational exercises addressing stated requirements. Mary is facilitating the workshop. Yi and Daniel are engineers.
Yi started; “This kind of estimation technique is called ‘planning poker.’”
“What’s planning poker?” asked Daniel.
“It’s an approach to overcoming some of the difficulties surrounding estimation” said Mary. “The problem of different people anchoring their estimates in others’ figures, you know, when the first person picks a number out of the air, and you go along with it just because it’s out there”.

Yi added; “We have a list of stories captured from the requirements study.” (Table 1)
Mary explained, “Our goal is to size these stories for the next iteration. We’ll be using the story points I talked about before, remember this is just to get a general feel for the size and difficulty of the story before we talk about how long it will take.”

“Shouldn’t I be thinking in terms of how long it’ll take?” said Daniel.
“Not yet,” said May, “this way we’ll get a general feel for the size, complexity, and difficulty of the story, and maybe even agree some of the detail and what the story means.”
Yi spoke up, “each of you take the numbered cards. Think of estimates ranging between ‘small, medium, and large’. We deal with duration after we’ve got a feel for difficulty and complexity.”

Note: Estimation challenges include: anchoring behaviour, task misinterpretation, not understanding one task's relationship to other tasks.


References and Links
Inspired by ‘Agile Estimating and Planning’ (Cohn, 2006).

Planning Poker Workshop

I put this video together to introduce and document the Planning Poker workshop from 2010.

Planning Poker Estimation. from Allen Higgins on Vimeo.

Exercise: Battleship as a metaphor for Plans or Planning

This game may be all you'll ever need to know about project management :-)

You Lost! €-300.000

Exploring the relationship between action and plans, having a plan and planning, design and designing.(note: the game uses a dot "." separator for 'thousands' as per common usage in many countries) 

The Rules of Planning Battleship

• There are 5 ships hidden in the grid - one ship of size 2, two ships of size 3, one ship of size 4, and one ship of size 5.  
• Reveal the ships by taking shots at grid coordinates.
• Each shot costs 10.000.
• You have a balance of 400.000 to spend on shots (i.e. equivalent to taking 40 shots).
• Try to generate a positive return.
• You only receive a payout if a whole ship is revealed. The payout is worth the ship size * 50,000.

Step 1: Design a pre-prepared plan of attack
Individuals produce one or more up-front plans using provided blank sheets.

Step 2a: Play Planning Battleship using the 40 shots per iteration game.

1. Open the playable version of battleship on https://tech.zilverline.com/battleship/public/index.html
2. Enter each of your pre-prepared plan of attacks.
3. Record your results in the survey form (survey form here) - these will be numbers from 1 - 40 and values from -400000 and above that are multiples of 10000.

Step 2b: Play Planning Battleship using the 10 shots per iteration game.

Step 2c: Play Planning Battleship using the 1 shots per iteration game.

Step 2d: Play Planning Battleship using another number of shots per iteration game.

Step 3:
Look at the results (data spreadsheet here)


Discussion:
What is an 'iteration' with respect to the game?

When does it make sense to run a project without feedback?

What is the 'design' with respect to the game?
What is 'strategy'  ?
What is 'project planning' ?
What (if anything) might this exercise highlight for projects in general?

What is the maximum payout? *1. 

What is the maximum cash position possible? *2.

Acknowledgement to Zilver - Zilverblog The Power of Feedback in Scrum:

Zilverline developed this simple version of the Battleship game, written in Javascript, as a tool to explore ideas related to the design and development and dynamics of projects.

• The difference between Plans and Planning
• The value of feedback
• Cost and reward
• The size of an effort versus the payback in terms of information
• The game-like nature of projects (like pinball, the goal is to play again?)

"Board layouts are random and you get 40 shots in total to destroy the enemy’s fleet. After each iteration you get feedback about hits and misses. If you use iterations of 1, you are playing the regular battleship-game. Each shot costs 10.000 and when you sink a ship you get the_ships_size * 50.000 (e.g. the submarine of size 3 will reward you with 150.000). If you keep track of the balance after each iteration, you could also try to get across the idea that stopping after a few iterations might give ‘good enough’ rewards."

The game can be downloaded from the GitHub repository as a zip or you can take a look at our code. Just double click on the index.html (in the public folder) to start a game.

Source code from Zilverline - https://github.com/zilverline/battleship

*1. Max payout from hits will be 5 ships of total size 17 * 50,000 = 850,000

*2.  Max cash position will be 1,080,000 (based on spending exactly 17 shots to gain 850000 and retaining 23 shots worth 230000, resulting in a retained profit of 1080000). Note that the game engine cannot be completed in this scenario.