Feature Slicing and Management Workshop by agileethos

Feature Slicing and Management Workshop Darian Rashid darian@agileethos.com 732-213-8522

ÂŠ Agile Ethos. Do Not Reproduce

Feature too to fit?

Â© Agile Ethos. Do Not Reproduce

Big 2

e d i v Di nd er A qu n o C

Â© Agile Ethos. Do Not Reproduce

User Stories •

A sentence or a paragraph that describes functionality of the system from the user’s perspective

•

Stories take the following format: As a <type of user> I can <perform some task> [so that I can <achieve some goal>]

•

Stores have 3 parts (the 3 ‘C’s): – Card: The written description of the story – Conversation: Verbal discussions that bring out further details of the system – Confirmation: the conditions of satisfaction that are used to determine when the feature is complete

•

Should also include key conditions or constraints

User Stories: Start with the Epic As a last-minute traveller, I would like to book full vacation packages a few days before the trip so that I can take advantage of the last-minute discounts

 Verify that I can customize my package  Verify I can search the best deals  Verify that I can choose from different destinations

•

The details are in the Conditions of Acceptance (CoAs) on the back of the card – These are referred to as Conditions of Satisfaction in Scrum – Conditions of Acceptance is less ambiguous

•

Should not contain architectural details

•

Augment with other documents, but only if necessary

Types of Stories Epic

A collection of stories. Also called a “compound story”

Complex Story

Stories that cannot be naturally broken down. Usually need more investigation (usually via spikes) to understand.

Minimum The smallest set of functionality that must be realized Marketable Feature in order for the customer to perceive value. (MMF) Vertical Slice (a.k.a., feature increment)

A part of an MMF that encompasses all architectural layers and can meet the definition of done. Vertical slices may not be shippable due to scope but are of shippable quality

Spike

A brief timeboxed period to gain further understanding and overcome an obstacle to planning or execution.

Splitting Epics to MMFs •

Turn each CoA into its own user story on the next level As a last-minute traveller, I would like to book full vacation packages a few days before the trip so that I can take advantage of the last-minute discounts

 Verify that I can customize my package  Verify I can search the best deals  Verify that I can choose from different destinations

As a last-minute traveller, I would like to choose from different destinations so that I can choose the best one for me

As a last-minute traveller, I would like to customize my package so I can get exactly what I need

As a last-minute traveller, I would like to search for the best deals so that I can meet my budgetary needs

Splitting Epics to MMFs

As a last-minute traveller, I want to be able to customize my packages

• •

 Verify that I can customize my flights  Verify I can customize my schedule  Verify that I can customize my hotel

Create CoAs for each new level Repeat until the Minimal Marketable Feature (MMF) level

As a last-minute traveller, I want to customize my flights

As a last-minute traveller, I want to customize my schedule As a last-minute traveller, I want to customize my hotel

Splitting Epics to MMFs 2

As a last-minute traveller, I want to be able to search for the best deals

 Verify that I can search by travel time  Verify I can search by price  Verify that I can search by destination

As a last-minute traveller, I want to be able to search by destination

As a last-minute traveller, I want to be able to search by travel time

As a last-minute traveller, I want to be able to search by price

Splitting On Multiple Levels • •

Epics and large stories may need multiple levels of splitting Don’t need to be at the same level for each path on the tree

xxxxx

EPIC

COMPOUND STORY

MMF

xxxxx MMF

xxxxx COMPOUND STORY

xxxxx

MMF

COMPOUND STORY

xxxxx xxxxx xxxxx MMF

xxxxx

xxxxx xxxxx MMF xxxxx

MMF

MMF © Agile Ethos. Do Not Reproduce

xxxxx MMF

User Stories Owned by the Product Owner who: •

Collaborates with customers and stakeholders to elicit using – – – – –

•

Collaborates with financial analysts to obtain – – – – – –

•

Story-writing workshops Observations Focus groups One-on-one interviews Questionnaires

Profit gained Market share growth Risks avoided Costs cut / Efficiencies added Cost of development Return on Investment

Collaborates with developers to obtain – – –

Risks Technical tradeoffs Story size

Disambiguating Your MMFs •

Document user flows – Pull out individual scenarios – the individual paths through the workflow

•

Document CoAs from user flows in Gherkin format – Will be used to derive test specifications (test cases used as requirements)

•

Document the technical constraints

•

Add any other pieces (customer comments, notes, etc.) that are deemed valuable and necessary

Technical Constraints •

A.k.a. Non-functional requirements

•

Should always provide performance requirements

•

Should provide the “-ilities” − − − − − −

•

Availability Efficiency Flexibility Integrity Interopretability Maintainability

− − − − −

Portability Reliability Reusability Robustness Usability

Technology and architectural constrains are provided by PO ONLY if absolutely necessary – “Business has a deal with Oracle and we’re not allowed to use anything else” – “Legal has restricted us from using anything with a GPL2 license”

Using Gherkin As CoAs for the Full MMF FEATURE: One Time Payment This feature lets the user make a one time payment using either her credit card or her bank account BACKGROUND: GIVEN I will be on the “One Time Payment” page SCENARIO: Happy Path – One Time Payment Using a Credit Card WHEN I fill out my information AND I click on the “Continue” button … THEN I will be on the “Thank You” Page SCENARIO: User clicks cancel in the Credit Card Information page – Negative WHEN …

But…Agile Says No Documentation! •

No. Agile says only the documentation that is – Valuable – Will be consumed for a purpose downstream – Will add value later on (history)

•

No documentation for some process that will never be consumed

• •

DOCUMENTATION is NOT a bad word – it’s a record And BTW, PROCESS is NOT a bad word – its HOW we work

•

PRODUCE AND DO ONLY WHAT IS USEFUL AND VALUABLE

•

So where’s the value in creating Epics/MMFs/User Flow Diagrams/CoAs?