Agile Estimating and Planning

[material inspired by Agile Estimating and Planning by Mike Cohn] Laurie Williams North Carolina State University williams@csc.ncsu.edu

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 formulate a project plan and schedule

Laurie Williams 2007

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 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 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 teams rate of progress

Laurie Williams 2007 3

Coming up with the plan

Desired Features 5 story points/twoweek iteration 30 October

30 story points

6 iterations

Laurie Williams 2007

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 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 100 dog points A dog point represents the height of a dog at the shoulder
Labrador retriever Terrier Great Dane Poodle Dachshund German shepherd St. Bernard Bulldog
Harder or easier?

More or less accurate?

More or less time consuming?

Laurie Williams 2007

Estimating story points

Choose a medium-size story and assign it a 5 Estimate other stories relative to that
Twice as big g 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

Laurie Williams 2007

Estimating ideal days

Ideal days vs. elapsed time in software development

Supporting current release Sick time Meetings Demonstrations Personal issues Phone calls ....

When estimating g ideal days, y , assume:

The story being estimated is the only thing youll work on Everything you need will be on hand when you start There will be no interruptions

Laurie Williams 2007

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

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 smaller, easier-to-estimate easier to estimate pieces/tasks. pieces/tasks Need to make sure you dont miss any tasks. Sanity check: does the sum of all the parts make sense?

Planning poker
Combines expert opinion, analogy, disaggregation
Laurie Williams 2007 9

Playing Planning Poker

Include all players on the development team (but less than 10 people overall):
Programmers Wideband Delphi Testers 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 estimate All cards simultaneously turned over Discussion ensures Re-estimate Repeat until converge
Laurie Williams 2007 10

Coming up with the plan

Desired Features

Laurie Williams 2007

11

Velocity

Velocity is a measure of a teams 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.

Yesterdays weather

Laurie Williams 2007

12

Coming up with the plan

Desired Features 5 story points/twoweek iteration October 30

30 story points

6 iterations

Laurie Williams 2007

13

Not working as fast as planned?

Desired Features 3 story yp points/two5 story week points/twoiteration week iteration 25 December October 30

30 story points

6 iterations 10 iterations

Laurie Williams 2007

14

Not working as fast as planned?

Desired Features 3 story yp points/two5 story week points/twoiteration week iteration October 30

30 story points 18 story points

6 iterations

Laurie Williams 2007

15

Velocity corrects estimation errors

Since all user stories are estimated relative to each other . . . Its the velocity that should change, not each story point estimate for future releases

Laurie Williams 2007

16

Coming up with the plan

Desired Features

Laurie Williams 2007

17

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 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 g Priority y Give us these stories to p provide a minimal working system. Medium Priority We need these stories to complete this system. Low Priority Bells and whistles? Which stories can come later?
Laurie Williams 2007 18

Coming up with the plan

Desired Features

Laurie Williams 2007

19

Burn down charts

Work Remaining (hours)

Vertical axis shows number of story points or hours remaining in the project Iterations [or days] are shown across the horizontal line Shows the amount of work remaining at the start of each iteration Visual indicator of how quickly a team is moving toward its goal

400 350 300 250 200 150 100 50 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Scrum Day

Laurie Williams 2007

20