back to notes

Vertically slicing user stories - an enterprise agile transformation clinic

Vertically slicing user stories - an enterprise agile transformation clinic

Thank you for joining us!

Introductions
Clinics: user stories series
Coaches
Today’s topic - vertical slicing
What is a user story?
Why do we slice vertically?
What is vertical slicing?
Objectives
Understand concept
Learn how to slice a story
Notes: Learning Objectives. Understand the concepts of vertical slicing. Understand how to cut through layers in each story

Start with why
Break work into smaller pieces
Achieve flow
Cross-sectional work
Notes: Why do we vertically slice?
Smaller pieces / control the scope of the work within the sprint, remove dependencies on sequence or phases
Flow / smaller pieces are more easily managed within a sprint and are more likely to be completed within the sprint. Decision making is data-driven and enabled through fast feedback
Optimize continuous and sustainable throughput of value
Avoid start-stop-start project delays
Build quality in; flow depends on it
Understand, exploit and manage variability
Integrate frequently
Informed decision-making via fast feedback
Cross-sectional work / present a function or transaction in its entirety before integration rather than integrate layers of technology

Agilepedia
Glossary Term - Definition
Sprint - is a development time-box; may be 2 or 3 weeks
User Story - describes a business need and provides a clear business value to the end-user
Definition of Ready - conditions a user story meets before it can be committed
Product Backlog - collection of prioritized user stories for a particular product
Sprint Backlog - stories committed to be completed during Sprint
Definition of Done - conditions a user story must meet before it can be accepted
Acceptance Criteria - demonstrate whether a user story passes or fails

What is a user story?
A user story…
As a (customer)
I want to (action)
So that I can (value)

Card, conversation, confirmation
Describes the customer, customer need, and resulting benefit
Delivers business value
Contain acceptance criteria
Owned by product owner; updated by team

Notes:What is a user story?
Commitment to a conversation, noted by Ron Jeffries as the 3Cs
Includes statement of need with clear benefit for that need
Statement of need includes business value to the customer
Clear and concise acceptance criteria is included to determine if the value and benefit are achieved
Product Owner controls the Product Backlog, yet everyone contributes to user stories
Clear statement of business need expressed with value expected. Provides the basis of the change that is desired. Written from a customer perspective.
Rachel Davies proposed this format (As a, I want, so that) in 2003, and it in commonly used in the industry.

I.N.V.E.S.T. in your user stories
For every user story, ask the team, is it:
User Stories should able to pass the “INVEST” test
Independent - One user story should be independent of another (as much as possible). Dependencies between stories make planning, prioritization, and estimation much more difficult. Often enough, dependencies can be reduced by either combining stories into one or by splitting the stories differently.
Negotiable - A user story is negotiable. The "Card" of the story is just a short description of the story which do not include details. The details are worked out during the "Conversation" phase. A "Card" with too much detail on it actually limits conversation with the customer.
Valuable - Each story has to be of value to the customer (either the user or the purchaser). One very good way of making stories valuable is to get the customer to write them. Once a customer realizes that a user story is not a contract and is negotiable, they will be much more comfortable writing stories.
Estimable - The developers need to be able to estimate (at a ballpark even) a user story to allow prioritization and planning of the story. Problems that can keep developers from estimating a story are: lack of domain knowledge (in which case there is a need for more Negotiation/Conversation); or if the story is too big (in which case the story needs to be broken down into smaller stories).
Small - A good story should be small in effort, typically representing no more, than 2-3 person weeks of effort. A story which is more than that in effort can have more errors associated with scoping and estimation.
Testable - A story needs to be testable for the "Confirmation" to take place. Remember, we do not develop what we cannot test. If you can't test it then you will never know when you are done. An example of non-testable story: "software should be easy to use".

Ensure quality is built in
INVEST by Bill Wake:
Independent - Avoid dependencies with other stories whenever possible. Able to deliver as a product increment independently
Negotiable -Stories are NOT a contract, break them up or add additional stories or information if necessary. Too much detail up front gives the impression that more discussion later is not necessary.
Valuable - Should deliver value to: Users, Stakeholders. The Scrum team needs to remember that value is subjective.
Estimable - Enough details are understood by the team to estimate. Can be challenged if stories are too large, or if we lack of domain knowledge.
Sized appropriately - Stories in the near future are small enough to be completed in a single Sprint. Stories further out can be larger (“Epics”).
Testable - Acceptance Criteria provide understanding up front what it will take for the story to be accepted by the Product Owner.

Practical application: let’s use the white board for a story
Notes: Use this activity to solicit a user story from the audience and write it out on the whiteboard. Does it include a statement of need? A benefit? Business value? Is it written from a user perspective.
Use the below example if no one has an example:
As a customer, I want to read global articles about technology so that I can stay up to date on trends around the world.

What is vertical slicing?
It’s not fencing, or sword play :)

When stories are too big….
Horizontal slices build across layers.
Integrate with other slices once all slices are complete
Cause delay and risk

Notes: **TALK ABOUT USUAL** how so much work is done today – the horizontal slices which create dependencies and ‘wait’ or ‘float’ time. Implications: Risk and delay

Vertical slicing helps
Cut through technology layers in a single story
Use for splitting user stories
Define incremental value
Focus on end-to-end, not point-to-point

Notes: ***TALK ABOUT WHY***

Why do we vertically slice?
Smaller pieces / control the scope of the work within the sprint, remove dependencies on sequence or phases
Flow / smaller pieces are more easily managed within a sprint and are more likely to be completed within the sprint. Decision making is data-driven and enabled through fast feedback
Optimize continuous and sustainable throughput of value
Avoid start-stop-start project delays
Build quality in; flow depends on it
Understand, exploit and manage variability
Integrate frequently
Informed decision-making via fast feedback
Cross-sectional work / present a function or transaction in its entirety before integration rather than integrate layers of technology
Vertical slicing is a recommended way of approaching user stories in an Agile environment. This method follows a function end to end through a system, through the layers of technology to initiate and fulfill the function. These slices are done in a single story rather than across a number of dependent stories. Splitting user stories into vertical slices requires practice. Vertical slicing does not focus on one layer at a time, nor does it focus on point-to-point transactions of a system.
Support – Splitting user stories virtual coffee or clinic

Vertical slicing – concept
Vertical slices focus on business functions
Complete single function end to end
Integrate with other functions.

Notes: ***SLICE WITHIN SPAN OF CONTROL*** Talk about minimizing dependencies as much as possible, and what is required to manage those conflicts
Horizontal slices build across layers. They cannot be integrated until all horizontal slices are completed. This mimics a waterfall structure
Vertical slices focus on a set of business functions that can be completed in a single story. By cutting through the user interface, middleware, and data layers, you can complete a single function, end-to-end, and integrate with other vertical slices.

Everything in it’s place
Epic
As a Wells Fargo customer,
I want to be able to manage my checking account balance
So I can take control of my finances.
Features
View balance
Account management
Stories
As a customer
I want to see current balance
so that I know what I have in my account.
As a customer
I want to see pending charges
so that I can forecast my future balance.
As a customer
I want to log in with a password
so I know my know information is safe.
As a customer
I want my account to automatically log out after inactivity
so my account is protected.

Notes: Basically Size and Time. Stories are completed within a sprint, and are self-contained, stand alone value propositions. Features are typically built up over multiple sprints – made up of multiple stories. Epics are enormous – deployed over multiple releases and can contain multiple features and MANY stories.

Practical application: let’s use the white board for another story…

Notes: Use a user story if someone has one, otherwise use example from slide 14. As a customer I want to see current balance so that I know what I have in my account.

Let’s review
What a user story is and how it is used
Vertical slicing
Minimizing risk through vertical slicing
Applying vertical slicing to user stories

Q & A
Please provide feedback;
it helps us continually improve!

Thank you for joining us!