View
271
Download
2
Category
Tags:
Preview:
Citation preview
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
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
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
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.
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
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.
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.
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.
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
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
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)
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
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.
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.
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
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).
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
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
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
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
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 __
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
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.
Recommended