This is a presentation I made in the beginning of this year to explain the basics of agile Estimates. Although the presentation doesn't cover exceptions and some special cases (like in the case of hours estimates) it's a good starting point. A text to understand better the presentation will come on my channel on Medium soon.

1. Agile Estimates – Insights about
the basic
Diogo Del Gaudio

2. Why estimate?
 Reducing risk
 Reducing uncertainty
 Supporting better decision making
 Estabilishing trust
 Conveying information

3. What makes a good plan?
 A good plan supports decisions because
 It’s somewhat predicative
 People can use them for making decisions

4. What makes a good plan?
 A good plan supports decisions because
 It’s somewhat predicative
 People can use them for making decisions

5. What makes planning agile?
 Incremental change
 Adaptation
 Focus on valuable features

6. What makes planning agile?
 More focused on the planning than on the plan
 Encourages change
 Results in plans are easily changed
 Is spread throughout the project

7. Why planning fails?
 ”Nearly two-thirds of projects significantly overrun their costs estimates (Lederer and
Prasad 1992)
 Sixty-four percent of the features included in products are rarely or never used (Johnson
2002)
 The average project exceeds its schedule by 100% (Standish 2001)

8. Why planning fails?
 Customers get no value from task completion.
 When the schedule is overrun quality tends to be sacrificed
 Change-control policy (even highly valuable changes)

9. Activity-based planning
 Activities dont’ finish early.
 Lateness is passed down the schedule
 Activities are not independent

10. Activities don’t finish early
 Work expands so as to fill the time available for its completion (Parkinson’s Law 1993)
 If the task is finished early ”Gold-plating” gets in action.

11. Why planning fails?
 Activities are not independent
 Multitasking causes furthers delays
 Features are not developed by priority
 We ignore uncertainty
 Estimates (that someone else gives you) become commitments

12. Multitasking will kill you

13. Why planning fails?
 Activities are not independent
 Multitasking causes furthers delays
 Features are not developed by priority
 We ignore uncertainty
 Estimates Become commitments

14. An agile approach
 Individual and interactions over process and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

15. An agile approach to projects
 Work as one team
 Work in short iterations
 Deliver something each iteration
 Focus on business priorities
 Inspect and adapt

16. Roles – Product owner
Certifies that the whole team persues a common vision for the project.

17. Roles – Customer
The person who has made the decision to fund the project.

18. Roles – Developer
Anyone developing the software.

19. Roles – Project Manager
Focused on leading the team.

20. An agile approach to projects
 Work as one team
 Work in short iterations
 Deliver something each iteration
 Focus on business priorities
 Inspect and adapt

21. Short iterations
 Timeboxing
 2-4 weeks

22. An agile approach to projects
 Work as one team
 Work in short iterations
 Deliver something each iteration
 Focus on business priorities
 Inspect and adapt

23. Deliver something each iteration
Iteration = Intern
Release = Extern

24. An agile approach to projects
 Work as one team
 Work in short iterations
 Deliver something each iteration
 Focus on business priorities
 Inspect and adapt

25. Focus on business priorities
 Focus on value
 Use user-stories

26. User-stories
”As a <Type of user>, I want <capability> so that <business value>”

27. An agile approach to projects
 Work as one team
 Work in short iterations
 Deliver something each iteration
 Focus on business priorities
 Inspect and adapt

28. Inspects and adapt
 A plan is a point-in-time guess
 Do, fail, learn, progress, repeat

29. Multiple levels
of planning

30. Estimating a task with hours
 Your working hours is not linear
 You assume 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
 Your amount productive hours are not as many as you think
 The value added to a client’s product is not the result of just your work
 Ideal time isn’t elapsed time

31. Overhead on a working day
 Supporting the current release
 Sick time
 Meetings
 Demonstrations
 Personnel issues
 Phone calls
 Special projects
 Training
 E-mail
 Reviews and walk-throughs
 Interviews
 Task switching
 Bug fixing in current releases
 Management reviews
 And much more…

32. Estimating size with story points
 Story points are relative
 Story points are consequent
 Story points are a combination of observations
 Story points are used to estimate effort, not hours

33. A combination of observations
Story points are a combination of observations:
 Amount of effort involved in developing the feature
 The risk inherent in it
 And so on…

34. Estimate with story points
1. Select the story you expect to be the smallest stories
2. Estimate the other stories based on the smallest one

35. Velocity
 Velocity is a measure of a team’s rate of progress.
 Velocity = Number of story points completed during the iteration
 Velocity corrects estimation errors

36. Velocity - Example
 Team TK finishes 5 stories, with 2 story points each on a 2 weeks iteration
 Team’s Velocity = 10

37. Velocity corrects estimation errors
 Project contains 200 points of work
 25 points per iteration
 8 iterations

38. Velocity corrects estimation errors
Once the project begins:
Their observed velocity is 20
Without re-estimating any work we know that the project will take 10 iterations
instead of 8

39. How does it fit
the schedule?
Deriving duration = number of
story points to
accomplish/Velocity

40. Advantages
 We decrease uncertainty what is good for us and for the client
 We can use the results to identify and solve bottlenecks in the process
 We estabilish trust with the client delivering what we promissed to deliver
 We remove the stress of estimating in hours from one person and instead let the whole
team decide the effort needed to accomplish a task

41. How much effort
is necessary to be
accurate on the
estimate?

42. Estimates are shared
 On an agile project we tend not to know specifically who will perform a given task
 Even though we already expect a person to be responsible for the task, others may have
something to say about the estimate. It means:
 Chance for feedback and brainstorming
 Shared knowledge
 Use of things learned on previous iterations

43. The estimation scale
 We are best at estimating things that fall within one order magnitude (Miranda 2001;
Saaty 1996)
 0,1,2,3,5,8

44. Planning poker
 Include all the members on the team
 The team has max 10 people
 The product owner participates in planning poker but without estimating (unless they are
coding)

45. Planning poker – How to:
1. Each estimator is given a deck of cards that reads 0,1,2,3,5,8
2. A moderator (usually the product owner) reads the description of an user story. The P.O
might (or not) remember the team about the effort/accuracy curve.
3. The team has the chance to ask questions
4. After all questions are answered each estimator privately selects a cart representing the
estimate
5. At the same time, all the cards are turned over and shown to all other participants
6. Repeat the estimates for the story if necessary

46. When to play planning poker
 First, The planning poker is done in the beginning of the project or during it’s first iterations
 Second, estimating new stories that are identified during an iteration. One way to do this is
to plan to hold a very short estimation meeting near the end of each iteration
 it’s important that the team is conscious that it’s a work that takes time but, as showed in
the presentation, it’s profitable

47. Why it works?
 Planning poker brings together multiple expert opinion to do the estimating
 The participants of planning poker have to justify their estimate
 It’s fun

48. Make projects great again!
Tack!