1. Agile Estimation & Sizing
Introduction (v1.0)

2. Today Welcome Purpose Estimating & Sizing in Agile
Points & Planning Poker
Exercise 1 – Planning Poker
Break
Planning and Execution
Exercise 2 – Estimating for Real
Summary
Q&A
Evaluation

3. Welcome REMEMBER Where are the bathrooms When will we have breaks
How does lunch work?
Fire exits...

4. Video recording
We intend to video record the training so we can improve as trainers.
Do you have a problem with this?

5. Turn off your mobile phone Shut down your computer
Focus your attention
Tell attendees when they can answer phone calls and answer s (When is lunch)
Out of Service

6. Safe space for learning
Please help the learning process by respecting the following:
We are all here to learn
We do not place judgment
No questions are stupid when they help us to learn
It will be great if you can also promise each other that:
Whatever happens in the room, stays in the room
Make sure to create a safe space for learning.
If you skip this, there is a risk that appearance will be more important than learning.
Give attendees time to read it

7. Some basic rules If you see someone with their hand in the air:
Be silent
Raise your arm
If a question is blocking you from learning or understanding, then please ask. If we can answer it, we will. Else we will write a post-it, and address it at the end of the section
If you feel uncomfortable asking a question in public, then catch us during a break
Defer ongoing questions and discussions to the ”Parking lot” (make sure to have a place on the wall for that)

8. Who’s who Start with yourself.
Remember you set the tone, so if you tell a lot, they will do the same.
Use timeboxes of 30 sec?

9. Today Welcome Purpose Estimating & Sizing in Agile
Points & Planning Poker
Exercise 1 – Planning Poker
Break
Planning and Execution
Exercise 2 – Estimating for Real
Summary
Q&A
Evaluation

10. Purpose REMEMBER Where are the bathrooms When will we have breaks
How does lunch work?
Fire exits...

11. Estimating and Sizing Workshop
This half-day workshop will familiarize participants with the “Planning” and “Execution” Agile estimation approach:
For “Planning” the approach for estimating Epics, Capabilities and Features will be discussed, with hands-on experience of estimation techniques, such as “planning poker”, provided;
For “Execution” we will look at estimating techniques for Stories and Tasks using Story Points and Hours respectively.

12. . Why we are here? The purpose of this training is to:
Understand how estimating and sizing is done in agile
Introduce the concept of “points” and planning poker
Undertake a practice sizing session
Explain how sizing differs across the backlog items
Planning – Epic, Capability, Feature
Execution – Story, Task
Illustrate sizing in the context of the wider agile delivery process .

13. Learning Objectives for this training
We will answer the following questions:
Who does sizing and estimating?
What are points? And How do you play planning poker?
How is sizing different between planning and execution?

14. The Question Board ?

15. Today Welcome Purpose Estimating & Sizing in Agile
Points & Planning Poker
Exercise 1 – Planning Poker
Break
Planning and Execution
Exercise 2 – Estimating for Real
Summary
Q&A
Evaluation

16. Estimating & Sizing in Agile

17. Agile Estimating
Nobody can predict the future – so why do we force people to? In Agile we estimate by size not by time Sizing is “relative” and not “absolute” Sizes can be measured in various ways e.g. “Story” Points Points are just a number We use past knowledge We use expert advice Remember – It’s just an estimate!

18. The Team doing the work are the best people to size the work!
The SM does not normally estimate but facilitates the estimating process
The PO does not estimate, but should be on hand to clarify questions

19. Scrum Process in Nordea
PI meeting
Estimating is either part of Product Backlog Refinement, or can be a separate “ceremony”

20. Estimating is done on “Units of Value” and “Units of Work”
6 Levels of Backlog Element:
Initiative – strategic direction for Business impact
Epic – set of features enabling value
Capability – single valuable, generic functionality
Feature – that valuable functionality on 1 channel
Story – 1 aspect or usage of a feature
Task – an activity performed to realize a story
Units of Strategy
… Is refined into 1 or more …
… Is refined into 1 or more …
Units of Value
… Is refined into 1 or more …
… Is refined into 1 or more …
… Is refined into 1 or more …
Units of Work

21. Sizing is Abstract & Relative
We use “Bigness” or general size
Sizing is unit-less but relative
We use numeric values (not T-shirt sizes)
Ideally triangulate the stories being sized
A base-line can be established
• 28/10/2017

22. The Question Board ?

23. Today Welcome Purpose Estimating & Sizing in Agile
Points & Planning Poker
Exercise 1 – Planning Poker
Break
Planning and Execution
Exercise 2 – Estimating for Real
Summary
Q&A
Evaluation

24. Points & Planning Poker

25. Points
Points can be used at any level of the backlog “Story Points” as the name implies are used for sizing the “Story” unit of work “Epic Points” apply at the “Epic” level, etc. The “Task” unit of work can also be sized but this is often using “time” as the currency (e.g. hours) Points were created by Mike Cohn of Mountain Goat Software Points are numeric, which can help with commitment and velocity calculations Remember they are just a number…...

26. Point Definition

27. Points – Questions to Consider
Complexity: How many parts or components are involved? Are we using new technologies or skills? How many stakeholders do we need to consider? Are there any regulations to comply with?
Uncertainty: Have we done this before? Do we know who is involved? Are there pre-existing guidelines and standards we can follow? Do we have the skills in the Team?
Effort:
How much work is involved?
How many people will it take?
Do we need to time for preparation and completion?
What about meetings?
If all of these are “High” then score with a high number, if all of these are “Low” then score with a low number

28. Planning Poker 1 Iterative objective approach to estimating
Showing cards at the same time allows everyone free say – avoids domination by influential people
Encourages questions (why so high/low?)
Collaborative approach, emphasizes the team
Avoids one persons view of time with the team’s view of size
Everyone’s opinion is heard
Quick (and there are quicker methods)
Information is shared – treat as a learning experience

29. Planning Poker 2
Steps:
Each estimator is given a deck of cards, each card has an estimate on it
Product Owner reads a story and it’s discussed briefly
Each estimator selects a card with their estimate
Cards turned over together
Discuss the differences (especially outliers)
Re-estimate until estimates converge

30. Planning Poker 3 Fibonacci sequence cards are used
The Fibonacci sequence:
Every number after the first two is the sum of the two preceding ones
High numbers get large very quickly - the idea is that the larger the story is, the more uncertainty there is around it and the less accurate the estimate will be
The gaps between the numbers imply that you are forced to make a choice between the less/more uncertain stories
Stories are either the same, larger, or smaller, there is no “just bigger” or “more or less the same”
The human mind 'sees' a perceptible difference between 5 and 8 story points (or 13 and 20) than it does with 5 and 6 or 10 and 11.
No sitting on the fence!

31. The Question Board ?

32. Today Welcome Purpose Estimating & Sizing in Agile
Points & Planning Poker
Exercise 1 – Planning Poker
Break
Planning and Execution
Exercise 2 – Estimating for Real
Summary
Q&A
Evaluation

33. Exercise 1 – Planning Poker

34. Exercise: Lets play planning poker

35. TO BE PRINTED FOR EXERCISE

36. TO BE PRINTED FOR EXERCISE

37. TO BE PRINTED FOR EXERCISE

38. The Question Board ?

39. Today Welcome Purpose Estimating & Sizing in Agile
Points & Planning Poker
Exercise 1 – Planning Poker
Break
Planning and Execution
Exercise 2 – Estimating for Real
Summary
Q&A
Evaluation

40. Break: 30 Minutes

41. Today Welcome Purpose Estimating & Sizing in Agile
Points & Planning Poker
Exercise 1 – Planning Poker
Break
Planning and Execution
Exercise 2 – Estimating for Real
Summary
Q&A
Evaluation

42. Planning & Execution

43. Estimating on “Units of Value” and “Units of Work”
Epic – set of features enabling value
Unit of Value
Epic estimation is done by Product Team
Fibonacci, smallest Epic is 1 (the baseline)
Planning poker

44. Estimating on “Units of Value” and “Units of Work”
Capability – single valuable, generic functionality
Unit of Value
Capability initial estimation done by Product Team and Development Team Representative during Capability to Feature breakdown
Also Fibonacci
Planning poker

45. Estimating on “Units of Value” and “Units of Work”
Feature – that valuable functionality on 1 channel
Unit of Value
Feature initial estimation done by Product Team and Development Team Representative during Capability to Feature breakdown
Refinement done by Development Team during Feature Refinement sessions
Also Fibonacci
Planning Poker

46. Estimating on “Units of Value” and “Units of Work”
Story – 1 aspect or usage of a feature
Unit of Work
Story initial estimation done by Development Team during PI
Refinement (task breakdown) done by Development Team during Sprint Planning
Also Fibonacci, smallest Story is 1
Planning Poker

47. Estimating on “Units of Value” and “Units of Work”
Task – an activity performed to realize a story
Unit of Work
Task estimation done by Development Team during Sprint Planning
Estimated in hours
Used to verify Story sizing and Capacity planning

48. The Question Board ?

49. Today Welcome Purpose Estimating & Sizing in Agile
Points & Planning Poker
Exercise 1 – Planning Poker
Break
Planning and Execution
Exercise 2 – Estimating for Real
Summary
Q&A
Evaluation

50. Exercise 2 – Estimating for Real

51. INVEST model (E=Estimatable) Establish a baseline
Lets do it for real
Do we have some real Epic, Capabilities, Features or Stories? Or do we need to write some?
INVEST model (E=Estimatable)
Establish a baseline
What if a backlog item is too big? Break it down
• 28/10/2017

52. I can <functionality> so that <value>
User Story Format
As a <user role>,
I can <functionality>
so that <value>

53. The Definition of Done
The definition of done for the backlog item being sized should be on-hand during estimating as we are estimating and sizing what it takes to be “done”

54. Let’s do some work!
Try and estimate at least 3 real backlog items

55. The Question Board ?

56. Today Welcome Purpose Estimating & Sizing in Agile
Points & Planning Poker
Exercise 1 – Planning Poker
Break
Planning and Execution
Exercise 2 – Estimating for Real
Summary
Q&A
Evaluation

57. Summary

58. Summary Today we have gone through:
How estimating and sizing in Agile is different
The different levels of estimating, from planning through to execution
The various ceremonies where estimating takes place
Planning poker as a technique for estimating
Points as a metric for estimating

59. Today Welcome Purpose Estimating & Sizing in Agile
Points & Planning Poker
Exercise 1 – Planning Poker
Break
Planning and Execution
Exercise 2 – Estimating for Real
Summary
Q&A
Evaluation

60. Q&A

61. Today Welcome Purpose Estimating & Sizing in Agile
Points & Planning Poker
Exercise 1 – Planning Poker
Break
Planning and Execution
Exercise 2 – Estimating for Real
Summary
Q&A
Evaluation

62. Evaluation

63. Learning Objectives for this training
Did we answer the following questions:
Who does sizing and estimating?
What are points? And How do you play planning poker?
How is sizing different between planning and execution?

64. Thank You!

65. OPTIONAL SLIDES FOLLOW

66. The value of estimating

67. Story Points can help with:
In-sprint burndown tracking and “pivoting”:
The sum of story points for all stories brought into sprint = sprint commitment
Burndown used to track progress v commitment on a daily basis
If burndown not “on track” then decisions on priorities can be taken (the “pivot”)

68. Burndown Tracking Daily Scrum Refinement 2 weeks Sprint Planning
Development
Sprint Review
Retrospective
Daily Scrum
Refinement
2 weeks

69. Story Points can help with:
Velocity:
Measure of how much work a team has done (using story points, averaged over a number of sprints)
Not a prediction of exactly how much we will do in a particular sprint (“velocity is an output, not an input”)
A long-term measure of capacity that can be used in planning
Not comparable across teams - teams will develop a signature

70. Velocity sensitivities
• 28/10/2017

71. Velocity for long term planning
The Backlog
• 28/10/2017