User Stories
-
Upload
tathagat-varma -
Category
Software
-
view
830 -
download
3
description
Transcript of 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.
h0p://www.romanpichler.com/blog/agile-‐product-‐management-‐tools/agile-‐product-‐roadmap/
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?
h0p://www.romanpichler.com/blog/agile-‐product-‐management-‐tools/agile-‐product-‐roadmap/
….should be “DEEP”
• Emergent • PrioriIzed
• EsImated • Detailed Appropriately
D E
E P
From Product Roadmap to Product Backlog
h0p://www.romanpichler.com/blog/agile-‐product-‐management-‐tools/agile-‐product-‐roadmap/
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.
h0p://www.mountaingoatso8ware.com/blog/stories-‐epics-‐and-‐themes
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.
h0p://www.mountaingoatso8ware.com/blog/stories-‐epics-‐and-‐themes
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
48 © Jeff Pa0on, all rights reserved, www.AgileProductDesign.com
Planning incremental releases can be facilitated as a collaboraIve event
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