user stories

User Stories

Tathagat Varma h0p://managewell.net

h0p://leanso8wareengineering.com/2007/11/14/planning-‐a-‐month-‐or-‐less-‐ahead-‐is-‐not-‐enough/

Agile Planning Onion

Strategy

PorFolio

Product

Release

IteraIon

Daily

Product Management ArIfacts

IniIaI

ves

Epics

Them

es

Sprin

t Backlog

Prod

uct B

acklog

Prod

uct R

oadm

ap

Prod

uct V

ision

Tasks…

Stories

Scen

arios

Product Vision

•  Shared by All •  Desirable and InspiraIonal •  Clear and Tangible •  Broad and Engaging •  Short and Sweet

Product Vision – Elevator Pitch

For (target customer)

Who (statement of the need or opportunity)

The (product name) is a (product category)

That (key benefit, compelling reason to buy)

Unlike (primary compeIIve alternaIve)

Our product (statement of primary differenIaIon)

h0p://www.joelonso8ware.com/arIcles/JimHighsmithonProductVisi.html

Product Vision Box

•  As the name suggests…

•  Describes the top 2-‐3 features of product

Product Roadmap

h0p://www.romanpichler.com/blog/agile-‐product-‐management-‐tools/agile-‐product-‐roadmap/

h0p://dynamicsgpblogster.files.wordpress.com/2009/04/dynamicsgproadmap4.png

•  High-‐level plan that describes how the product will evolve

•  Refers to •  Product version •  FuncIonality •  Release date

Product Backlog

•  A combined list of all desired work, including user focused stories, technical work, features & ideas

•  Everything is expressed in User Stories •  List is prioriIzed by the Product Owner •  Product Owner keeps it organized with the team’s help

•  Anyone can add items to the backlog •  Evolves over Ime •  Always in progress

Benefits of Product Roadmap

•  Helps communicate how you see the product develop. •  Helps align the product and the company strategy. •  Helps manage the stakeholders and coordinate the development, markeIng, and sales acIviIes.

•  Facilitates effecIve porFolio management, as it helps synchronise the development efforts of different products.

•  Supports and complements the product backlog. This allows the backlog to focus on the tacIcal product development aspects.


Product Backlog •  The agile product backlog is a prioriIzed

features list, containing short descripIons of all funcIonality desired in the product.

•  When using Scrum, it is not necessary to start a project with a lengthy, upfront effort to document all requirements.

•  Typically, a Scrum team and its product owner begin by wriIng down everything they can think of for agile backlog prioriIzaIon. This agile product backlog is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers.

•  h0p://www.mountaingoatso8ware.com/scrum/product-‐backlog

Who owns Product Backlog?


….should be “DEEP”

•  Emergent •  PrioriIzed

•  EsImated •  Detailed Appropriately

D E

E P

From Product Roadmap to Product Backlog


Sprint Backlog

•  User Stories selected by The Team

•  Will be built in next Sprint

•  Fully EsImated •  Divided into Tasks

Sprint Backlog

User Story

I as a <Role>

want <Feature>

so that <Value>

Why User Stories?

h0p://www.agilebuddha.com/wp-‐content/uploads/2012/05/User-‐Stories.jpg

Why not ‘PRDs’?

User Story

h0p://www.leadingagile.com/wp-‐content/uploads/2012/07/post-‐it-‐note-‐user-‐story.jpg

h0ps://code.google.com/p/econference-‐planning-‐poker-‐plugin/wiki/PlanningPoker

As a frequent flyer, I want to be able to view current offers in terms of mileage points so that I can redeem them.

Acceptance Criteria

22

Given <System State> when <an event occurs> then <an outcome happens>

The Three C’s of a User Story

• The story itself • A promise to have a conversaIon at the appropriate Ime

Card

• The requirements themselves communicated from the Product Owner to the Delivery Team via a conversaIon

• Write down what is agreed upon ConversaIon

• The Acceptance Criteria for the story • How the Delivery Team will know they have completed the story

ConfirmaIon

What makes a good User Story?

Independent of all others

NegoIable not a specific contract for features

Valuable or ver2cal

EsImable to a good approxima2on

Small so as to fit within an itera2on

Testable in principle, even if there isn’t a test for it yet

h0p://guide.agilealliance.org/guide/invest.html

Scenarios, User Case, User Story Use Case: Customer walks to the restaurant Customer enters the restaurant Customer finds a seat at the bar Customer scans the menu Customer selects a beer Customer orders selected beer Bartender takes order Bartender pours beer Bartender delivers beer User drinks beer User pays for beer

User Story: A user wants to find a bar, to drink a beer.

h0p://www.cloudforestdesign.com/2011/04/25/introducIon-‐user-‐stories-‐user-‐personas-‐use-‐cases-‐whats-‐the-‐difference/

Scenario: Josh is a 30 something mid-‐level manager for an ad agency, metro-‐sexual and beer aficionado. He likes to try new and exoIc beers in trendy locaIons. He also enjoys using a variety of social apps on his smart phone. He reads a review on Yelp of a new burger & beer joint downtown with over 100 beers on tap, and decides to go walk over a8er work and check it out.

Themes, Epics, Stories, Tasks

Themes

•  We could put a rubber band around that group of stories I wrote about monthly repor2ng and we'd call that a “theme.” Some2mes it's helpful to think about a group of stories so we have a term for that. S2cking with the movie analogy above, in my DVD rack I have filed the James Bond movies together. They are a theme or grouping.

h0p://www.mountaingoatso8ware.com/blog/stories-‐epics-‐and-‐themes

Themes change/evolve…

Scrum Product Ownership – Bob Galen

Epics •  A Scrum epic is a large user story. There's no magic threshold at

which we call a parIcular story an epic. It just means “big user story.” I like to think of this in relaIon to movies. If I tell you a parIcular movie was an “acIon-‐adventure movie” that tells you something about the movie. There's probably some car chases, probably some shooIng, and so on. It tells you this even though there is no universal definiIon that we've agreed to follow, and that an acIon-‐adventure movie must contain at least three car chases, at least 45 bullets must be shot, and ….

•  So, “epic” is just a label we apply to a large story. Calling a story an epic can someImes convey addiIonal meaning. Suppose you ask me if I had Ime yesterday to write the user stories about the monthly reporIng part of the system. “Yes,” I reply, “but they are mostly epics.” That tells you that while I did write them, I didn't get the chance to break most of them down into stories that are probably small enough to implement directly.


User Stories •  A user story is simply something a user wants.

User stories are more than just text wri0en on an index card but for our purposes here, just think of user story as a bit of text saying something like, “Paginate the monthly sales report” or, “Change tax calculaIons on invoices.”

•  Many teams have learned the benefits of wriIng user stories in the form of: –  As a <type of user> –  I <want/can/am able to/need to/etc.> –  so that <some reason>.

•  But it is not necessary that a user story be wri0en that way.


Epics -‐> Stories

Performance Constraint -‐> Acceptance Criteria

Minimal Marketable Feature •  A Minimal Marketable Feature (MMF) is a feature that is minimal,

because if it was any smaller, it would not be marketable. A MMF is marketable, because when it is released as part of a product, people would use (or buy) the feature.

•  An MMF is different than a typical User Story in Scrum or Extreme Programming. Where mulIple User Stories might be coalesced to form a single marketable feature, MMFs are a li0le bit bigger. O8en, there is a release a8er each MMF is complete.

•  An MMF doesn’t decompose down into smaller sub-‐feature, but it is big enough to launch on its own.

•  A MMF can be represented as a User Story — a short, one-‐sentence descripIon.

MVP, MMF, Stories

MVP

MMFs

User Stories

MoSCoW

•  M -‐ MUST: Describes a requirement that must be saIsfied in the final soluIon for the soluIon to be considered a success.

•  S -‐ SHOULD: Represents a high-‐priority item that should be included in the soluIon if it is possible. This is o8en a criIcal requirement but one which can be saIsfied in other ways if strictly necessary.

•  C -‐ COULD: Describes a requirement which is considered desirable but not necessary. This will be included if Ime and resources permit.

•  W -‐ WON'T: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future. (note: occasionally the word "Won't" is subsItuted for "Would" to give a clearer understanding of this choice.

Spliung User Stories

h0p://gojko.net/2012/01/23/spliung-‐user-‐stories-‐the-‐hamburger-‐method/

1. IdenIfy Tasks

2. IdenIfy opIons for tasks

3. Combine Results

4. Trim the Hamburger

5. Take the first bite!

6. Take another bite…and conInue

User Story Mapping

45 © Jeff Pa0on, all rights reserved, www.AgileProductDesign.com

The user story map contains two important anatomical features

•  The backbone of the applicaIon is the list of essenIal acIviIes the applicaIon supports

•  The walking skeleton is the so8ware we build that supports the least number of necessary tasks across the full span of user experience

time

necessity

The backbone

The walking skeleton

Scenarios

•  A usage scenario, or scenario for short, describes a real-‐world example of how one or more people or organizaIons interact with a system.

•  They describe the steps, events, and/or acIons which occur during the interacIon.

•  Usage scenarios can be very detailed, indicaIng exactly how someone works with the user interface, or reasonably high-‐level describing the criIcal business acIons but not the indicaIng how they’re performed.

Learning and Emergence

EsImaIon

h0p://www.agilenutshell.com/episodes/3-‐esImaIon

Use any measure…consistently

Story Points •  Agile teams generally prefer to express esImates in units other

than the Ime-‐honored "man-‐day" or "man-‐hour". Possibly the most widespread unit is "story points".

•  One of the chief reasons is the use of velocity for planning purposes. "Velocity", in the sense Agile teams use the term, has no preferred unit of measurement, it is a dimensionless quanIty. Velocity allows teams to compute the expected remaining duraIon of the project, as a number of iteraIons, each iteraIon delivering some amount of features.

•  Another important reason has to do with the social and psychological aspects of esImaIon: using units such as story points, emphasizing relaIve difficulty over absolute duraIon, relieves some of the tensions that o8en arise between developers and managers around esImaIon: for instance, asking developers for an esImate then holding them accountable as if it had been a firm commitment.

h0p://guide.agilealliance.org/guide/nuts.html

EsImaIon Mainly two forms of esImaIon –  Analogous EsImaIon [T-‐Shirt Sizing -‐ S,M,L,XL]

•  This Story is like another Story (maybe a li0le more difficult, maybe a li0le less)

•  Give this Story a comparable esImated value. •  EsImate against mulIple Stories of the same effort. •  Analogous esImaIon is successful due to our inherent ability to be0er measure relaIve size than absolute size.

–  Planning Poker •  Each esImator is given a deck of cards, each card contains a valid esImate.

•  Fib ––1,2,3,5,8,13,20,301,2,3,5,8,13,20,30 •  Story is read and discussed briefly •  Each esImator selects a card that reflects their esImate. •  Cards are turned over for all to see. •  Discussion takes place •  Re-‐esImate to try to get convergence.

Affinity EsImaIng Guidelines

Break up into small teams of 2-‐4

Discuss 2-‐3 stories so there is a sense of them

Find an iniNal comparaNve story

•  If team is already SprinIng, find a small-‐ish one already completed that was a really good esImate; use that esImate

• Or find a fully understandable story and fully task it out; call it either a 2 or a 3

Without conversaNon, the enNre team puts all the stories on a big wall

• Smallest at the right and largest on the le8 compared to iniIal story • Anyone can move anyone else’s story posiIon

As acNvity subsides, put a scaled number line up

SeQle on esNmates for boundary stories and epics

Affinity EsImaIng

56

References •  h0p://www.scrumcrazy.com/A+User+Story+Checklist •  h0p://www.scrumcrazy.com/User+Story+Basics+-‐+The+Longer

+Story •  h0p://www.scrumcrazy.com/The+ScrumCrazy.com+User+Story

+Maturity+Model •  h0p://www.romanpichler.com/blog/wriIng-‐good-‐user-‐stories/ •  h0ps://en.wikipedia.org/wiki/User_story •  h0p://www.mountaingoatso8ware.com/agile/user-‐stories •  h0p://www.agilemodeling.com/arIfacts/userStory.htm •  h0p://www.agileproductdesign.com/presentaIons/

user_story_mapping/ •  h0p://agileatlas.org/arIcles/item/user-‐stories •  h0p://training-‐course-‐material.com/training/

Scrum_Product_Owner

user stories

Software