The document provides an introduction to agile estimation and release planning. It discusses building a product backlog by creating user stories, estimating each story using complexity buckets and points, and ensuring user stories meet INVEST criteria. It also covers splitting large user stories, acceptance criteria, and ensuring the product backlog is DEEP by being detailed, estimated, emergent, and prioritized. Estimation techniques include relative sizing to other stories and complexity buckets for different aspects like user interface, business logic, etc. The document emphasizes that estimation is about relative size rather than fixed timelines and that consistency is more important than absolute accuracy.

1. AN INTRODUCTION
TO AGILE
ESTIMATION AND
RELEASE PLANNING
James Whitehead

2. INTRODUCTION
⦿ Building the product backlog
⦿ Estimation
⦿ DEEP
⦿ Splitting your user stories
⦿ Planning
◼ Release Planning

3. PRODUCT BACKLOG
⦿ A list of user stories form your Product
Backlog. Often termed PBI (Product Backlog Item)
As a xxxxx I
want xxx so
that xxxx
As a xxxxx I
want xxx so
that xxxx
As a xxxxx I
want xxx so
that xxxx
As a xxxxx I
want xxx so
that xxxx
As a xxxxx I
want xxx so
that xxxx
As a xxxxx I
want xxx so
that xxxx

4. ESTIMATE EACH ITEM
How long is this going to take?
- 1 day ?
- 1 week?
- Forever?

5. ESTIMATE EACH ITEM
How long is this going to take?
- 1 day ?
- 1 week?
- Forever?
Estimates are not time based but relative
to each other

6. ESTIMATE EACH ITEM
⦿ Is
⦿ likely to take longer than
⦿ ?
⦿ Remember estimation is relative sizing!
#1
#2

7. Why Is estimation so
hard?

9. 2 – ESTIMATE EACH ITEM
RELATIVE ESTIMATION
Estimating Story Points Using Complexity Buckets
⦿ This approach provides a consistent way for teams to size
stories by discussing each story in terms of pre-defined
buckets of complexity before deciding on the final points.
⦿ The steps are simple:
◼ Decide on the buckets of complexity you think match your
project. For example, many software development efforts
have the buckets used below.
◼ Discuss the story in each bucket and determine if the team
can agree if the work it has a Light, Medium, High or Complex
level of complexity.
◼ Add up the points and see which Fibonacci Story Point bucket
it falls into. If it falls between two buckets, have the team do
a gut check and decide on which ones it falls into.

10. 2 – ESTIMATION
HELPFUL TIPS
User Interface Business Logic Data/Integration Testing
L = 1 L = 1 L = 1 L = 1
M = 2 M = 2 M = 2 M = 2
H = 3 H = 3 H = 3 H = 3
C = 4 C = 4 C = 4 C = 4
Helpful Considerations Helpful Considerations Helpful Considerations Helpful Considerations
- number of screen
fields?
- number of business rules? - number of data stores - user testing complexity
- Screen validation
logic?
- business rules complexity - complexity of Stored
procedures/triggers
- data setup complexity for
each test pack
- number of screens? - number of
tables/relationships
- test automation complexity
1 2 3 5 8 13 21
Example
As a customer, I want to browse the list of products so that I view the details.
User interface: M = 2
Business Logic: N/A
Data: L = 1
Testing: L = 1
Total is 4 points, which is between 3 and 5, team decide on 3.

11. USER INTERFACE
⦿ L = 1
⦿ M = 2
⦿ H = 3
⦿ C = 4
⦿ Helpful Considerations
◼ - number of screen fields?
◼ - Screen validation logic?
◼ - number of screens?

12. BUSINESS LOGIC
⦿ L = 1
⦿ M = 2
⦿ H = 3
⦿ C = 4
⦿ Helpful Considerations
◼ - number of business rules?
◼ - business rules complexity

13. DATA/INTEGRATION
⦿ L = 1
⦿ M = 2
⦿ H = 3
⦿ C = 4
⦿ Helpful Considerations
◼ - number of data stores
◼ - complexity of Stored procedures/triggers
◼ - number of tables/relationships

14. TESTING
⦿ L = 1
⦿ M = 2
⦿ H = 3
⦿ C = 4
⦿ Helpful Considerations
◼ - user testing complexity
◼ - data setup complexity for each test pack
◼ - test automation complexity

15. EXAMPLE
As a customer, I want to browse the list of
products so that I can view the details.
User interface: M = 2
Business Logic: N/A
Data: L = 1
Testing: L = 1
Total is 4 points, which is between 3 and 5,
team decide on 3 because the business logic is
not applicable.

16. INVEST
Letter Meaning Description
I Independent
The user story should be self-contained, in a way that there is
no inherent dependency on another user story.
N Negotiable
User stories, up until they are part of a sprint, can always be
changed and rewritten.
V Valuable A user story must deliver value to the business
E Estimable You must always be able to estimate the size of a user story.
S Sized appropriately or
Small
User stories should not be so big as to become impossible to
plan/task/prioritize with a certain level of certainty.
T Testable
The user story or its related description must provide the
necessary information to make testing of the development
possible.
The INVEST mnemonic was created by Bill Wake as a reminder of the characteristics of a good quality
user story, as may be used in a Scrum backlog.

17. INDEPENDENT
⦿ The user story should be self-contained,
in a way that there is no inherent
dependency on another user story.

18. NEGOTIABLE
⦿ User stories, up until they are part of a
sprint, can always be changed and
rewritten.

19. VALUABLE
⦿ A user story must deliver value to the
business
◼ Value can be monetary
◼ Gain more customers
◼ Coming up with technical stories that are really
fun to code but bring no value to the end-user
violates one of the Agile Principles, which is to
continuously deliver valuable software to the
business.

20. ESTIMABLE
⦿ You must always be able to estimate the
size of a user story.
◼ If a user story size cannot be estimated, it will
never be planned, tasked, and, thus, become
part of a sprint.
◼ So there's actually no point in keeping this kind
of user story in the Product Backlog at all.

21. TESTABLE
⦿ The user story or its related description
must provide the necessary information to
make testing of the development
possible.
◼ Remember here these tests can be part of your
conditions of satisfaction or acceptance criteria.

22. SIZED APPROPRIATELY
⦿ User stories should not be so big as to
become impossible to plan/task/prioritize
with a certain level of certainty.
◼ Try to keep your user story sizes to typically a few person-days
and at most a few person-weeks. Anything beyond that range
should be considered too large to be estimated with a good
level of certainty or even "epic" and broken down into smaller
user stories.
◼ There's no problem in starting with epic stories, as long as they
are broken down when the time to place them in a sprint
backlog becomes closer

23. OR SMALL
◼ Try to keep your user story sizes to typically
a few person-days and at most a few person-
weeks. Anything beyond that range should be
considered too large to be estimated with a
good level of certainty or even "epic" and
broken down into smaller user stories.
◼ There's no problem in starting with epic
stories, as long as they are broken down
when the time to place them in a sprint
backlog becomes closer

24. MY USER STORY IS TOO BIG
⦿ What do you do if the estimation is too big!!

25. EXAMPLE OF A USER STORY
(THIS IS AN EPIC)
⦿ As a Director of Marketing, I
want to review the
performance of historical
advertising campaigns so that
I can identify profitable
campaigns worth repeating.

26. INVEST
Independent
The user story should be self-contained, in a way that there is no inherent dependency on another
user story.
Negotiable
User stories, up until they are part of a sprint, can always be changed and rewritten.
Valuable
A user story must deliver value to the business
Estimable
You must always be able to estimate the size of a user story.
Sized appropriately or Small
User stories should not be so big as to become impossible to plan/task/prioritize with a certain level
of certainty.
Testable
The user story or its related description must provide the necessary information to make test
development possible.

27. INVEST
Independent
The user story should be self-contained, in a way that there is no inherent dependency on another
user story.
Negotiable
User stories, up until they are part of a sprint, can always be changed and rewritten.
Valuable
A user story must deliver value to the business
Estimable
You must always be able to estimate the size of a user story.
Sized appropriately or Small
User stories should not be so big as to become impossible to plan/task/prioritize with a certain level
of certainty.
Testable
The user story or its related description must provide the necessary information to make test
development possible.
Has too many dependencies on other stories
You could negotiate on parts of the story
Clearly there is business value here avoids spending on
campaigns and maximises investment in good campaigns
Can you really size this properly.
This story is very large and not small at all
There are so many test here on data and output to get
testing into shape is complex and time consuming

28. EXAMPLE OF A USER STORY
(STILL EPICS)
⦿ As a Director of Marketing, I want to select
the timeframe to use when reviewing the
performance of past advertising campaigns so
that I can identify profitable ones.
⦿ As a Director of Marketing, I want to select
which type of campaigns (direct mail, TV, e-
mail, radio and so on) to include when
reviewing the performance of historical
advertising campaigns.

29. EXAMPLE OF A USER STORY
(THREE STORIES)
◼ As a Director of Marketing, I want to set simple
date ranges to be used when reviewing the
performance of past advertising campaigns so
that I can pick an exact set of dates.
◼ As a Director of Marketing, I want to select
seasons (spring, summer, autumn, winter) to be
used when reviewing the performance of past
advertising campaigns so that I can view trends
across multiple years.
◼ As a Director of Marketing, I want to select a
holiday period (Easter, Christmas and so on) to
be used when reviewing the performance of past
advertising campaigns so that I can look for
trends across multiple years.

30. EXAMPLE OF A USER STORY
3 STORIES OR ARE THEY CONDITIONS OF
SATISFACTION (ACCEPTANCE CRITERIA)???
◼ Set simple date ranges of past advertising
performance
◼ Pick an exact set of dates.
◼ Select seasons (spring, summer, autumn, winter)
◼ View trends across multiple years.
◼ Select a holiday period (Easter, Christmas and so
on)
◼ Review performance trends across multiple
years.

31. SOME MORE TIPS ON
SPLITTING USER STORIES

32. SPLITTING USER STORIES
(CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE)
⦿ 1. Workflow Steps
◼ What steps does a user perform?
◼ Are all steps necessary (right now)?
◼ Can steps be simplified (for now)?
◼ i.e. steps in an order process, like
selecting a payment option, delivery
method.

33. SPLITTING USER STORIES
(CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE)
⦿ 2. Business Rules
◼ What rules apply to this story
◼ Are all business rules necessary (right now)?
◼ Can simpler rules suffice (for now)?
◼ i.e. failures during webshop order process
and possible recovery options maybe done as
a later user story.

34. SPLITTING USER STORIES
(CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE)
⦿ 3. Happy/Unhappy flow
◼ What does the happy/unhappy flow look like?
◼ Are all unhappy flows necessary (right now)?
◼ Can unhappy flows be simplified (right now)?
◼ i.e. failures during webshop order process
and possible recovery options

35. SPLITTING USER STORIES
(CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE)
⦿ 4. Input options
◼ Which platforms are supported?
◼ Are all platforms required (right now)?
◼ Are some platforms harder than others?
◼ i.e. tablet, iPhone, desktop, touchscreen PC

36. SPLITTING USER STORIES
(CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE)
⦿ 5. Datatypes and parameters
◼ What datatypes are supported?
◼ What parameters are relevant?
◼ i.e. different search options/strategies or
different kinds of reports (table, graphs etc)

37. SPLITTING USER STORIES
(CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE)
⦿ 6. Operations
◼ What operations does this story entail?
◼ Are all operations necessary (right now)?
◼ i.e. splitting down CRUD (create, read,
update, delete) operations

38. SPLITTING USER STORIES
(CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE)
⦿ 7. Test cases/ acceptance criteria
◼ What tests are used to verify this story?
◼ What acceptance criteria apply?
◼ Are all test scenarios necessary (right now)?
◼ i.e. some test scenarios may be very complex
and not highly relevant to the context of this
user story.

39. SPLITTING USER STORIES
(CAN YOU SPLIT A STORY VERTICALLY LIKE A SLICE OF CAKE)
⦿ 8. Roles
◼ What roles are involved in this story?
◼ Are roles necessary now?
◼ i.e. customer can create orders,
administration can manager orders, pickers
can pick and order, packers can pack and
order and shipping can ship the order.

40. SUMMARY
⦿ Stories will change
⦿ Everyone estimates
⦿ Points are NOT a unit of time but relative
⦿ Being consistent is more important than
being accurate
⦿ Estimates must include uncertainty

41. ACCEPTANCE CRITERIA
OR CONDITIONS OF
SATISFACTION

42. GOOD ACCEPTABLE CRITERIA AND
TESTS
⦿ S – Specific – Explicitly defined and definite
⦿ M – Measureable – Possible to observe and quantify
⦿ A- Achievable – Capable of existing and taking place
⦿ R – Relevant – Having a connection with the story
⦿ T – Time-bound – When will the outcome be observed

43. SPECIFY BY EXAMPLE
Data
Expected
Result
Expected
Message
Aa9ab$ Fail Too Short
AAbbCC11 Fail
No Special
Characters
$$$bbb111 Fail No Upper Case
AAA%% Fail No Lower Case
AAAA%%%%
bbbbb
Fail No numbers
IsThis$AGood1
1
Pass

44. DEEP

45. DEEP
How DEEP is your Product Backlog.
The product backlog should have the following
key attributes (DEEP):
(D)Detailed appropriately
(E)Estimated
(E)Emergent
(P)Prioritized

46. DETAILED APPROPRIATELY
⦿ User stories that are high priority are
described in detail so that they can be well
understood before they can be completed in
the coming sprint.
⦿ Stories that are on low priority should have
“just enough” details and they can be
refined over time.

47. ESTIMATED
⦿ Product backlog also acts as a planning tool
other than acting as a work to do repository.
⦿ The items on the backlog are estimated and
the estimates for the user stories down the
order are usually less precise because all the
details are not understood yet.
⦿ They can be refined overtime.

48. EMERGENT
⦿ The product backlog is not static. It evolves,
and its contents change over time.
⦿ As more is learned and discovered, user
stories are added to the product backlog.
⦿ Existing user stories are modified, re-
prioritized, refined, or removed on a regular
basis.

49. PRIORITIZED
⦿ All items in the product backlog are
prioritized.
⦿ Teams select high-priority items from the
backlog. If there is no effort estimate, or if it
needs review, a new estimate is created.
⦿ The most valuable and highest-priority items
are implemented first and the least valuable
ones at last.
⦿ This approach of following the priority order
helps teams to maximize the value of the
product or system being developed for the
business (Product Owner).

50. PRIORITISE
2 6 4
2 4 6
2 4 4

51. PRIORITISE
⦿ - Apply a Business Value
2 6 4
2 4 6
2 4 4

52. PRIORITISE
⦿ - Prioritise By Business Value
2 6 4
4 4 6
4 2 2

53. SUMMARY - PRIORITISE
⦿ It is important for the team to help the
Product Owner prioritise and get into the
mind of focus on the right things
⦿ It helps the development team focus on
doing things right
⦿ Remember the Product Owner has the final
word
⦿ Technical dependencies are relevant
⦿ Priorities will change over time

54. VELOCITY
⦿ What is all this talk about velocity!
⦿ Velocity is the amount of stories completed
during a sprint that can then be estimated or
planned for future sprints.

55. SPRINTS – PLANNED VELOCITY
8 10 14 14 14 18
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6
2
2
2
2
2
4
2
2
2
2
4
6
4
4
4
2
2
4
6
2
2
4
6
6
What if we don’t have enough history of Agile/Scrum
to
get the velocity
Planned Velocity

56. 2 10 14 14 14 18
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6
Velocity
SPRINTS

57. 2 10 14 14 14 18
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6
Velocity = 12
SPRINTS
Velocity is the number of completed stories divided by the planned sprints

58. SUMMARY
⦿ Planned Velocity is useful only until we have
real data - just an educated guess
⦿ “Yesterday’s weather” is more important
than average
⦿ Sprints must create production-quality
potentially shippable products
⦿ Velocity is specific for a team as each team
is unique

59. 5 – MIN BREAK

60. PLANNING

61. PLANNING
⦿ So how do we plan in Agile/Scrum

62. CANDIDATE SCHEDULE
⦿Say planned
velocity is 6

63. CANDIDATE SCHEDULE
⦿Say planned
velocity is 6
⦿Backlog is 34 points
total

64. CANDIDATE SCHEDULE
⦿34 /6 = 6 Sprints

65. CANDIDATE SCHEDULE
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6
2
4
6 2
4
2
4
6 4

66. CANDIDATE SCHEDULE
⦿ Remember no more than 6
as this is your velocity!
⦿ (Yes you can negotiate within the
team but be careful remember it is
a team commitment not you as an
individual)

67. CONCLUSION
⦿ This is just a framework - there are multiple
variants
⦿ The Product Owner and Business (Subject
Matter Experts) are partners during
estimation and planning
⦿ Don’t try to change the world, change your
plan

68. MONITOR AND ADAPT
⦿ You can’t embrace change and have a plan
written in stone
⦿ Re-estimate whenever necessary
⦿ Don’t try and force real life to look like
your plan - It’s the other way around

69. MONITOR AND ADAPT

70. RELEASE PLANNING

71. MONITOR AND ADAPT
⦿ Plans are nothing.
⦿ Planning is everything.
Dwight D. Einsenhower

72. RELEASE PLANNING – WHERE DOES
IT FIT IN AGILE/SCRUM

73. PLANNING LEVELS
Product Backlog Release Backlog Sprint Backlog
Might have an initial
estimate (perhaps both
analysis and development
and an expression of
technical and business
confidence that this is
real and achievable
As a __, I want
to be able to
__ so that __
As a __, I want
to be able to
__ so that __
More detailed estimate
and a specific
acceptance test – low
confidence stories might
be spiked or prototyped
I will know this
is done when
_____
As a __, I want
to be able to
__ so that __
I will know this
is done when
_____
To do this I
must
1) ______
2) ______
Business Goal
Possible
automation
of the
acceptance
test
Development
team breaks
out the detail
of work needed
to pass test

74. RELEASE PLANNING
SCHEDULE
Apr May Jun Jul Aug Sep Oct Nov
Release
Meeting
1 2 3 4
Releases
1 1 2 2 3 3 4
Ideally a release planning meetings happens once every two months
to set the PBIs for the following Releases, just so happens we have
gone and set them against months above but…..

75. EXAMPLE RELEASE PLAN
Major Features
(Themes)
Sprint 1 Sprint 2 Sprint 3 Sprint 4 to 6 Quarter 2 Quarter 3 Year 2
Authentication
Login Screen
Security
Questions
SSO
Integration
with Partner
Sites
SSL Encryption
Order Entry
Product
Selection
Sponsored
Lookups
Product
Review
Product
Comparison
Checkout
Checkout Coupons
Order
Tracking
Reward Points
Release Plans
can be set
against Sprints
And Sprints can be between 1 to 4 Weeks in length.