an introduction to agile estimation and release planning

AN INTRODUCTION TO AGILE

ESTIMATION AND RELEASE PLANNING

James Whitehead

INTRODUCTION⦿ Building the product backlog⦿ Estimation⦿ DEEP⦿ Splitting your user stories⦿ Planning

◼ Release Planning

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






ESTIMATE EACH ITEM

How long is this going to take?

- 1 day ?- 1 week?- Forever?

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

ESTIMATE EACH ITEM⦿ Is

⦿ likely to take longer than

⦿ ?

⦿ Remember estimation is relative sizing!

#1

#2

Why Is estimation so hard?

2 – ESTIMATE EACH ITEMRELATIVE ESTIMATIONEstimating 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.

2 – ESTIMATIONHELPFUL TIPS

User Interface Business Logic Data/Integration TestingL = 1 L = 1 L = 1 L = 1M = 2 M = 2 M = 2 M = 2H = 3 H = 3 H = 3 H = 3C = 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.

USER INTERFACE⦿ L = 1⦿ M = 2⦿ H = 3⦿ C = 4⦿ Helpful Considerations

◼ - number of screen fields?◼ - Screen validation logic?◼ - number of screens?

BUSINESS LOGIC⦿ L = 1⦿ M = 2⦿ H = 3⦿ C = 4⦿ Helpful Considerations

◼ - number of business rules?◼ - business rules complexity

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

TESTING⦿ L = 1⦿ M = 2⦿ H = 3⦿ C = 4⦿ Helpful Considerations

◼ - user testing complexity◼ - data setup complexity for each test pack◼ - test automation complexity

EXAMPLEAs a customer, I want to browse the list of products so that I can view the details.

User interface: M = 2Business Logic: N/AData: L = 1Testing: L = 1

Total is 4 points, which is between 3 and 5, team decide on 3 because the business logic is not applicable.

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 TestableThe 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.

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◼ 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.

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.

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.

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

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

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

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.

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

NegotiableUser stories, up until they are part of a sprint, can always be changed and rewritten.

ValuableA user story must deliver value to the business

EstimableYou must always be able to estimate the size of a user story.

Sized appropriately or SmallUser stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.

TestableThe user story or its related description must provide the necessary information to make test development possible.

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

NegotiableUser stories, up until they are part of a sprint, can always be changed and rewritten.

ValuableA user story must deliver value to the business

EstimableYou must always be able to estimate the size of a user story.

Sized appropriately or SmallUser stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.

TestableThe 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

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.

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.

EXAMPLE OF A USER STORY3 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.

SOME MORE TIPS ON SPLITTING USER STORIES

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.


⦿ 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.


⦿ 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


⦿ 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


⦿ 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)


⦿ 6. Operations◼ What operations does this story entail?◼ Are all operations necessary (right now)?◼ i.e. splitting down CRUD (create, read,

update, delete) operations


⦿ 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.


⦿ 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.

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

ACCEPTANCE CRITERIAOR CONDITIONS OF

SATISFACTION

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

SPECIFY BY EXAMPLEData Expected

ResultExpected 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$AGood11 Pass

DEEPHow DEEP is your Product Backlog.The product backlog should have the following key attributes (DEEP):

(D)Detailed appropriately(E)Estimated(E)Emergent(P)Prioritized

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.

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.

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.

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).

PRIORITISE

2 6 4

2 4 6

2 4 4

PRIORITISE⦿ - Apply a Business Value

2 6 4

2 4 6

2 4 4

PRIORITISE⦿ - Prioritise By Business Value

2 6 4

4 4 6

4 2 2

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

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.

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 w

e don’t have

enough history

of Agile

/Scrum to

get the ve

locity

Planned Velocit

y

2 10 14 14 14 18


Velocity?

SPRINTS

2 10 14 14 14 18


Velocity = 12

SPRINTS

Velocity is the number of completed stories divided by the planned sprints

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

5 – MIN BREAK

PLANNING

PLANNING⦿ So how do we plan in Agile/Scrum

CANDIDATE SCHEDULE

⦿Say planned velocity is 6

CANDIDATE SCHEDULE

⦿Say planned velocity is 6

⦿Backlog is 34 points total

CANDIDATE SCHEDULE

⦿34 /6 = 6 Sprints

CANDIDATE SCHEDULESprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6

2

4

6 2

4

2

4

6 4

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)

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

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

MONITOR AND ADAPT

RELEASE PLANNING

MONITOR AND ADAPT

⦿Plans are nothing.

⦿Planning is everything.

Dwight D. Einsenhower

RELEASE PLANNING – WHERE DOES IT FIT IN AGILE/SCRUM

PLANNING LEVELSProduct 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 __


More detailed estimate and a specific acceptance test – low confidence stories might be spiked or prototyped

I will know this is done when _____


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

RELEASE PLANNINGSCHEDULE

Apr May Jun Jul Aug Sep Oct Nov

ReleaseMeeting 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…..

EXAMPLE RELEASE PLANMajor 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.

an introduction to agile estimation and release planning

Technology

number of business rules

number of screens

data stores complexity

number of tablesrelationships

test pack number

complex level of complexity

list of user stories

product backlog estimation