Agile Estimating and Planning

(1)

Agile Estimating and Planning

[material inspired by “Agile Estimating and Planning” by Mike Cohn]

Laurie Williams

North Carolina State University [email protected]

This lecture material is copyrighted by Laurie Williams (2007). However, you are encouraged to download, forward, copy, print, or distribute it, provided you do so in its entirety (including this notice) and do not sell or otherwise exploit it for commercial purposes.

Estimating and planning

 Estimating – estimating the [resources, time, size]

required to develop a [user story, feature, or requirement]

 Planning – putting the estimates together to

(2)

Estimating size: concepts

 Story point: unit of measure for expressing the

overall size of a user story, feature, or other piece of work. The raw value of a story point is unimportant. What matters are the relative values

What matters are the relative values.

– Related to how hard it is and how much of it there is

– NOT related to amount of time or # of people

– Unitless, but numerically-meaningful

 Ideal time: the amount of time “something” takes

when stripped of all peripheral activities

– Example: American football game = 60 minutesExample: American football game 60 minutes

 Elapsed time: the amount of time that passes on the

clock to do “something”

– Example: American football game = 3 hours

 Velocity: measure of a team’s rate of progress

Coming up with the plan

Desired Features

30 story points 6 iterations 5 story points/two-week iteration

30 October

(3)

Estimating “dog points”

 Estimate each of the dogs below in dog points,

assigning each dog a minimum of 1 dog point and a maximum of 10 dog points

 A dog point represents the height of a dog at the

shoulder –Labrador retriever –Terrier –Great Dane –Poodle Dachshund –Dachshund –German shepherd –St. Bernard –Bulldog © Laurie Williams 2007 ₅

What if?

 Estimate each of the dogs below in dog points,

assigning each dog a minimum of 1 dog point and a

maximum of 100dog points

 A dog point represents the height of a dog at the

shoulder –Labrador retriever –Terrier –Great Dane –Poodle Dachshund

More or less accurate? Harder or easier?

–Dachshund

–German shepherd

–St. Bernard

–Bulldog

(4)

Estimating story points

 Choose a medium-size story and assign it a “5”

 Estimate other stories relative to that

– Twice as bigg

– Half as big

– Almost but not quite as big

– A little bit bigger

 Only values:

–

0, 1, 2, 3, 5, 8, 13, 20, 40, 100

Near term iteration “stories”

A few iterations away “epic”

Estimating ideal days

 Ideal days vs. elapsed time in software development

– Supporting current release

– Sick time – Meetings – Demonstrations – Personal issues – Phone calls – . . . .

 When estimating ideal days, assume:g y ,

– The story being estimated is the only thing you’ll work on

– Everything you need will be on hand when you start

– There will be no interruptions

(5)

Deriving an estimate for a user story

 Expert opinion

–Rely on gut feel based on (extensive) experience

–Disadvantage for agile: need to consider all aspects of

developing the user story, so one expert will likely not be enough developing the user story, so one expert will likely not be enough

 Analogy

–Relative to (several) other user stories

–Triangulation: little bigger than that “3” and a little smaller than that “8”

 Disaggregation

Break up into smaller easier to estimate pieces/tasks

–Break up into smaller, easier-to-estimate pieces/tasks.

–Need to make sure you don’t miss any tasks.

–Sanity check: does the sum of all the parts make sense?

 Planning poker

–Combines expert opinion, analogy, disaggregation

Playing Planning Poker

 Include all players on the development team (but less

than 10 people overall):

–Programmers

–TestersTesters Wideband Delphi

–Database engineers

–Requirements analysts

–User interaction designers . . .

 Moderator (usually the product owner or analyst) reads

the description and answers any questions

 Each estimator privately selects a card with their estimateEach estimator privately selects a card with their estimate

 All cards simultaneously turned over

 Discussion ensures

(6)

Coming up with the plan

Velocity

 Velocity is a measure of a team’s rate of progress.

 Velocity is calculated by summing the number of

story points assigned to each user story that the team completed during the operation.

 We assume that the team will produce in future

iterations at the rate of their past average velocity.

–

“

Yesterday’s weather”

(7)

Coming up with the plan

30 story points 6 iterations 5 story points/two-week iteration

October 30

Not working as fast as planned?

3 story

points/two-30 story points 6 iterations 5 story points/two-week iteration October 30 y p week iteration 10 iterations 25 December

(8)

Not working as fast as planned?

3 story

points/two-30 story points 6 iterations 5 story points/two-week iteration October 30 y p week iteration 18 story points © Laurie Williams 2007 ₁₅

Velocity corrects estimation errors

 Since all user stories are estimated relative to each

other . . . other . . .

 It’s the velocity that should change, not each story

point estimate for future releases

(9)

Coming up with the plan

Prioritization

 Driven by customer, in conjunction with developer

 Choose features to fill up velocity of iteration, based on:

– Desirability of the feature to a broad base of customers or users Desirability of a feature to a small number of important customers

– Desirability of a feature to a small number of important customers or users

– The cohesiveness of the story in relation to other stories. Example:

» “Zoom in” a high priority feature » “Zoom out” not a high priority feature

 But it becomes one relative to “Zoom in”

 High Priority – “Give us these stories to provide a minimal g y p working system.”

 Medium Priority – “We need these stories to complete this

system.”

(10)

Coming up with the plan

Burn down charts

 Vertical axis shows

number of story points or

hours remaining in the 400

project

 Iterations [or days] are

shown across the horizontal line

 Shows the amount of

work remaining at the

start of each iteration 0

50 100 150 200 250 300 350 1234 56789 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 W o rk R e m a in in g ( hour s )

start of each iteration

 Visual indicator of how

quickly a team is moving toward its goal

1234 56789 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30