![Access
Your
SoluIon
• Did
you
cover
the
most
important
interac2ons?
• Is
each
user-‐triggered
story
an
end-‐to-‐end,
user-‐level
task?
(This
is
someImes
known
as
the
“Coffee
Break
Rule”:
Would
the
user
feel
like
it’s
a
good
Ime
to
take
a
coffee
break
aqer
compleIng
this
task?)
• Do
your
story
headings
follow
the
Role–Ac2on–Context
format?
• Are
your
headings
short
(typically
five
or
fewer
words,
rarely
if
ever
ten
words)?
• Are
your
headings
technology-‐
and
[user]
interface-‐independent?
• Are
you
seeing
a
domain-‐level
vocabulary
emerge?](https://image.slidesharecdn.com/composinguserstories-140712143640-phpapp02/85/Composing-User-Stories-Beginners-Guide-37-320.jpg)
![User
Story
Template
–
1
As
a
[user
role]
I
want
to
[goal]
• So
I
can
[reason]
• As
a
[type
of
user]
I
want
to
[perform
some
task]
so
that
I
can
[reach
some
goal]
Example:
• As
a
registered
user
I
want
to
log
in
• So
I
can
access
subscriber-‐only
content](https://image.slidesharecdn.com/composinguserstories-140712143640-phpapp02/85/Composing-User-Stories-Beginners-Guide-65-320.jpg)
Uploaded byRaja Soundaramourty
Composing User Stories - Beginners Guide
This document discusses user stories and their role in software development projects. It begins by outlining the typical process of planning, storytelling, coding, testing, and implementation. It then focuses on composing effective user stories, noting they should be concise written descriptions of functionality valuable to users. The document provides guidelines for writing user stories, including using a role-action-context structure for headings and including just enough detail to estimate, plan and evolve the system.
More Related Content
Similar to Composing User Stories - Beginners Guide
Composing User Stories - Beginners Guide
- 1. Composing User Stories Raja . S July 2014
- 2. We Are Here !!! Implementa2on Story Refinement Coding Tes2ng Planning Storytelling Chartering Project happen in a context, created by their charter Once you have some stories, you can plan with them Storytelling, the art of composing user stories, is the focus of this album Implementa2on involves some story-‐related acIviIes in refinement and tes2ng. We’ll touch on them slightly, but they’re mostly out of scope for this album This drawing is linear, but real projects move more freely among these acIviIes
- 3. What is in a ChaMer ? A Project’s Charter Drives the Stories You will Create. Whether formal or informal, a charter establishes clear expecta2ons between a sponsor and a team The charter answers key quesIons that set the context: • Vision: The ulImate end-‐state that will saIsfy the sponsor • Mission: The way in which we propose to accomplish the vision • Principles: What values guide the team’s behavior? • Objec2ves: What are the measurable , external outcomes for which the sponsor is funding the project. What tests will tell us if those objecIves were met? • Boundaries: What is the project responsible for? What comes in or goes out? What are the key events? • CommiLed Resources: What resources will be made available to the team? • Authorizing Players: Who is sponsoring the work? Who will judge it?
- 4. Telling Stories with the Product Backlog
- 5. Requirements = CommunicaIon Tool • Can be well thought through, reviewed and edited • Provide a permanent record • Are easily shared with groups of people • Time consuming to produce • May be less relevant or superseded over Ime • Can be easily misinterpreted WriLen Requirements • Instantaneous feedback and clarificaIon • InformaIon-‐packed exchange • Easier to clarify and gain common understanding • Easily adapted to any new informaIon known at the Ime • Can spark ideas about problems and opportuniIes Verbal Requirements
- 6. User Stories Seek to Combine the Strengths of WriLen and Verbal Communica2on, Where Possible Supported by a Picture. * Kent Beck Coined the Term User Stories in Extreme Programming Explained 1st EdiIon, 1999.
- 7. What is a User Story? A concise, wriLen descrip2on of a piece of func2onality that will be valuable to a user (or owner) of the soTware Stories are: • User’s needs • Product descripIons • Planning items • Tokens for a conversaIon • Mechanisms for deferring conversaIon
- 8. User Story – Ambiguity Yes, it is. You’ll hear “User Story” (or “story”) used to talk about at least three things: • The feature itself (whether implemented yet or not) • The “headline” wriMen on a card • The headline, details, discussions, and key tests that together describe a feature The context will tell you which meaning of story is in play. Isn’t the Term “User Story” Ambiguous?
- 9. A user story describes a s2mulus; the system produces results in response to that s2mulus • All stories have the same basic structure: Heading (Itle) and details User Story – Basic Structure Heading Details User Logs in with Expired License Take user to home page Disable all links and buttons Add prominent renewal link that takes user to the Store – Ask for exact text and location
- 10. The Heading: Role–Ac2on–Context The “Role–Ac2on–Context” formula works very well for wri2ng story headings that reflect events and responses: The words in the heading create and reflect a domain vocabulary: • The people using our system • How they can act • What they can act upon Heading – RAC Style Someone or something that sends a s2mulus into a system boundary How the role triggers the s2mulus. Usually as simple as verb + object Op2onal: Where or when the ac2on applies Role User Logs in with Expired License Ac2on Context
- 11. Good Headings Which are Good Headings? Which of the following fit the Role–Ac2on–Context formula (Good) and which Do Not? Good Bad 1. “The system shall process Visa™ cards.” 2. ATM Customer: Iden2fies self System: Presents op2ons for deposit, withdrawal, or fast cash ATM Customer: Selects fast cash etc. 3. “Student Schedules a Course” 4. “Grading”
- 12. As a type-‐of-‐user, I want to ac-on so that business-‐goal DescripIon – Connextra Style User stories replace detailed requirements and specificaIons with just enough detail. Just enough for what? For esImaIng, planning, understanding, discovering, and evolving the system, and basically, moving forward The details elaborate on the heading. They describe the sImulus, the response, and any specifics that maMer to the customer. The details shouldn’t be technical, nor should they spell out development tasks or guide implementaIon The Details Elaborate on the Heading You can use any simple means to write the details, as long as you get your point across: • A few phrases • Bullet points • Diagrams • Hand-‐drawn pictures “Wri2ng the Stories is Not the Point, Communica2ng is the Point” – Kent Beck and Mar-n Fowler
- 13. When Do We Get the Details • During planning sessions • Even deeper conversaIons about other details as they begin to implement the story • Decisions, details, and specificaIons can be captured in automated tests, as a picture, on a whiteboard, or by any other useful means • Key Principle: "Defer decisions unIl the last responsible moment.”
- 14. Pre-‐requisites Some details are clearly needed earlier than others.
- 15. Summary User Stories Provide a Lightweight Way to Manage Requirements. • “A user story is a chunk of funcIonality (some people use the word feature) that is of value to the customer.” • A story card consists of a heading (Itle) and details • The formula Role–AcIon–Context can help you write effecIve story headings • A story is useful even before we work out its details: “A user story is a promissory note for a conversaIon.” (Cockburn) • “CCC: Card, ConversaIon, ConfirmaIon” (Jeffries)
- 16. What Makes a User Story Good A Story Should be • Understandable to customers and developers • Testable • Valuable to the customer • Small enough so that the programmers can build half a dozen in an iteraIon – Kent Beck and Mar-n Fowler
- 17. INVEST – Acronym Bill Wake devised the acronym INVEST as a reminder of the properIes of good stories Independent Nego2able (and Nego2ated) Valuable Es2matable Small Testable Stories ideally describe non-‐overlapping bits of funcIonality, possible to implement in any order The customer, developers, and testers can agree on what the story means precisely enough that tests can be created Stories have flexibility; there’s room for a collaboraIve definiIon of success Stories’ value makes sense from a customer or end user’s perspecIve. They’re not described in terms of a developer’s tasks The team can esImate the difficulty of the story (at least to a rough level) The story is small enough for its purpose. For implementaIon, it can be completed in less than an iteraIon. For longer term planning, the story is larger
- 18. What Characterizes Great User Story Essen2al The user story describes something that helps achieve essenIal management objecIves External The user story perspecIve views the system as a black box, describing what is to happen, not how it happens Instantaneous The user story happens at an instant in Ime rather than over a duraIon of Ime Detectable The user story has an explicit sImulus (acIon-‐ or Ime-‐based)
- 19. EssenIal Stories • Essen2al user stories provide value to sponsors • What provides value? SoTware that helps achieve a project charter's vision, mission, or key objec2ves • Sponsors ul2mately care about effects, the changes in the outside world resul2ng from the system • Here is the vision statement project charter: § Rapidly spawned, knowledge workers, skilled in the fundamentals of collaboraIve learning § User stories that contribute to achieving this vision are essenIal. Thus, knowledge workers adds eIqueMes of collaboraIon in enterprise to his learning plan is essenIal because it lets Knowledge workers teach themselves § The story knowledge workers adds eIqueMes of poetry learning to his learning plan is not essenIal to the vision. In other words, it is not currently something valued by sponsors
- 20. External Stories • User stories that are external to a system boundary focus on organiza2onal and business concerns rather than technical ones • The user story perspec2ve views the system as a black box, describing what is to happen, not how it happens within the black box • The external, organiza2onally-‐focused language of user stories survives changes in technology; how a user story gets implemented is up to the programmers • A given user story might have hundreds of ways it could be implemented • When wri2ng User Stories, don't include any technological assump2ons about how the story "should" be implemented • User stories reflect end-‐to-‐end func2onality
- 21. Instantaneous Stories A Great Story Describes an Instantaneous Event. The story’s ac2on or event, happens at an instant in 2me rather than over a dura-on of 2me The phrase “Clock hands move around clock face” fails this criterion because there is no single instant in 2me during which that happens The clock’s hands reaching a certain posi2on or 2me would be an instantaneous event These stories headings are examples of instantaneous events • System sends daily summary email • Customer selects report
- 22. User stories are triggered by something – and that trigger must be detectable by the system Ed Yourdon (author of the classic, modern structured analysis) describes three types of event triggers: • Flow-‐oriented Events: Triggered by data arriving; the most common sort Example: Customer cancels order. • Temporal Events: Triggered by a point in Ime. Example: System processes credit cards at 9:00PM • Control Events: Triggered by external sImulus; common in real-‐Ime systems Example: Alarm sensor signals door open Detectable Stories
- 23. Quiz External Stories Quiz Please drag the boxes to re-‐order them from best to worst, in terms of their taking an external perspecIve of the system. Place these in the correct order: Student Reveals Answers Student Reveals Answers via JavaScript Student Clicks “Show Answers” Student Reveals Answers by Joining Quiz Answer Column in Quiz Table with Quiz QuesIon Table Instantaneous Stories Quiz For each item, tell whether it takes place at an Instant or over a Dura2on of Ime. We prefer stories with s2muli that are instantaneous, rather than occurring over a period of 2me. 1. Taxpayer Submits Tax Form 2. Admin Reads Report 3. Device Monitors Blood Pressure 4. User Selects Context-‐SensiIve Help Instant Dura2on Can You Hear Me Now? Which events are detectable? For each event, please tell whether it is Detectable or Not. 1. System is to send a warning noIce 3 days before library book is due 2. User presses keyboard key(s) to capture contents of the screen 3. Elevator passenger imagines going to the 12th floor 4. The developer runs into the project manager in the hallway and tells her that the task is completed 5. The government’s tax department has flagged your tax return and is considering whether to audit you. (This is from the perspecIve of the taxpayer, not the government) Detectable Not
- 24. • First, the mere existence of the story implies that the project community considers it important. Stories that actually get implemented are (hopefully) essen2al. If you don’t need the story, get rid of it. (If you track stories on cards, you’ll get a saIsfying feeling when you r-‐r-‐rip it up) • If you model the system’s interacIons properly, the role is usually an external enIty (user, accountant, another system) sending a sImulus into the system • Instantaneous events manifest themselves in the acIon, usually through the choice of the verb • When the means of interacIng with the system are clear, such as a buMon-‐click or API call, the acIon describes a detectable event • A proper context helps to pinpoint all the criteria, and helps us to write beMer stories Four Criteria's and RCA Format I’m not sure I understand how these four criteria relate to the Role–Ac2on–Context structure
- 25. Summary The Four Criteria: Essen2al, External, Instantaneous, and Detectable Can Help Keep Your Stories on Track 1 Essen2al: Valuable to sponsors (as part of the charter) 2 External: Takes an outside-‐the-‐system perspecIve 3 Instantaneous: Happens at a moment in Ime, not over an interval of Ime 4 Detectable: The system has a way to tell that the story is triggered
- 26. What are Roles When we say User, we’re usually talking about an individual, a person A role is an abstracIon: A name for how a parIcular group of people use the system The name “role” comes from theater: An actor plays a role by acIng like someone, but they don’t really become that person Even more common, a single role can be filled by different people: Many people are Shoppers A system may enforce roles (eg., only Administrators can install soqware), but we don’t require that Roles need not be explicit in the system: We can be a Browser and a Shopper, without any need for the system to keep track of which role we’re playing One person can have mul2ple roles: A person may be acIng like a Browser and a Shopper at different Imes in a single session Roles Iden2fy PaLerns of Using the System
- 27. Search Widely for Roles Roles help us create higher-‐value systems by focusing on the needs of par2cular groups of users A brainstorming and refinement process can help us iden2fy roles (from So6ware for Use by Constan2ne and Lockwood): • Compile – Brainstorm or otherwise generate as many candidates as possible • Organize – Review and sort them; understand their relaIonships; consolidate them • Detail – Fill in any missing data • Refine – Improve and complete the model Develop an Ini2al Model of Roles and Their Rela2onships.
- 28. Characters of Users Knowledge about users can help iden2fy missing roles and guide us in how we use roles Categories of users can suggest missing roles, and guide us in how we treat roles we know about Roles Characteris2cs Primary or Secondary Do we need to address this user’s needs sooner or can we wait Ill later? Example: Customer is a primary role for the vacaIon site; customers bring in money so we want to support them early Favored or Disfavored Are we trying to help this user or avoid helping them? Example: A compeItor is a disfavored user; we might add watermarks to our pictures t make it harder for compeItors to steal them Direct or Indirect Does this user operate they system themselves or does somebody else use the system on their behalf? Example: Customer is a direct user, while a Giq Recipient is an indirect user
- 29. Primary or Secondary Think about MyFakeVaca2on.info; which roles are Primary and which are Secondary? Primary Secondary 1. Marke2ng Manager: All the markeIng manager wants is that within six months of iniIal release, markeIng starts receiving reports monthly reports on the effecIveness of adverIsing campaigns 2. Vaca2on Creator: A member of the markeIng department who creates a vacaIon by uploading a set of compaIble photographs 3. Hacker: On Day 1, some hackers will try to score a free vacaIon by looking for bugs in the checkout process
- 30. Favored or Disfavored For MyFakeVaca2on.info; which stakeholders are Favored and which are Disfavored? Favored Disfavored 1. Purchaser of a vaca2on 2. Travelocity 3. Our photography partner 4. M4dd06h4x0r (a hacker)
- 31. Oqen ForgoMen Role You Won’t Support Every Stakeholder, But Look for Key Roles Beyond The Obvious Users. Certain roles are easy to forget because they’re oqen not everyday users of the system, but they an important impact on the acceptability of the system as a whole: • Administrators • Operators • Supervisors • ExecuIves • Auditors • Hackers and other disfavored users
- 32. Dig Deeper Deeper Knowledge about Users Can Suggest Useful Dis2nc2ons in Roles. Understanding these characterisIcs will be especially helpful in designing the interface. For the people in the roles you iden2fy: • What are their goals? • What is their domain exper2se? • What is their technology exper2se? • How oTen will they use the system? • What else is important about them?
- 33. How to Start? Refine, Revise, Redistribute Review with Project Community DraT Stories Use in Planning Suppose you’re just star2ng to write stories. How and where do you start? The following process is oTen useful: Does this look familiar? It’s a straighoorward interpreta2on of a standard Agile approach: So get a pen, a bunch of 3” x 5” index cards or a whiteboard, and start wri2ng! Start small and g r a d u a l l y improve your work.
- 34. This Sequence of Steps Can Help You Focus Your Story Wri2ng. A Procedure for Story Telling 1. Pick any area of the product, or any idea from your charter. 2. Iden-fy the main actor (role), or some leading actor • What would this person do? • What does this person care about? • Ignoring the users interface, what does this person try to achieve? Turn the answers into stories: Role, Ac2on, Context 3. Does a story depend on another, unwriLen story? Write that story. (We prefer independent stories, but not at the cost of missing stories) 4. Is there some overlap between stories? No worries. Ideally, you can redistribute their purpose (to make them independent); if not, keep them as is.
- 35. Being Adventurous Gather a group of people and brainstorm. What do you absolutely have to do to accomplish the project’s mission? (psst: Try this without the developers in the room, to increase the focus on the business need) Something doesn’t feel right? Tear up some cards for good measure If you write a “wishful thinking” story: What would the soqware have to support before that story could ever be considered? That’s another set of stories Ignore the plan, write everything down Browse the table of contents or top-‐level headings of an exisIng spec, recasIng the funcIonality as stories
- 36. Tips • Review your charter and/or mission; have you missed anything needed to support it? • Consider the project community – users and stakeholders; are there users or needs you haven’t addressed? • Review what you’ve done with someone else • Look at your domain vocabulary. Stories you’ve already wriMen will have people (roles), acIons, and objects. Are there combinaIons that suggest a new story you need? • Shuffle your stories in various ways: By role, by when it happens, by priority, by esImate. Does this suggest any stories? • Move on. If you’re not used to wriIng stories, you may be surprised by how few high-‐ level stories you need. Maybe it’s Ime to move on to stories that will be implemented soon, working out details such as business rules or tests If You Get Stuck While Wri2ng Stories, Try These Ideas:
- 37. Access Your SoluIon • Did you cover the most important interac2ons? • Is each user-‐triggered story an end-‐to-‐end, user-‐level task? (This is someImes known as the “Coffee Break Rule”: Would the user feel like it’s a good Ime to take a coffee break aqer compleIng this task?) • Do your story headings follow the Role–Ac2on–Context format? • Are your headings short (typically five or fewer words, rarely if ever ten words)? • Are your headings technology-‐ and [user] interface-‐independent? • Are you seeing a domain-‐level vocabulary emerge?
- 38. Summary • There are a variety of ways to organize your story wri2ng. Think about your charter, about product areas, about roles, acIons, and contexts • You’ve pracIced wriIng stories in the Role–Ac2on–Context format • You can use the self-‐assessment quesIons to help you asses stories in live projects
- 39. SECOND BATCH (REST 27 SLIDES)
- 40. System and Boundary Consider the soTware owned and run by a small doctor’s office to manage its appointments, medical records, and insurance claims. Which of the following are Inside the system boundary and which are Outside? Inside Outside 1. Recep2onist (who schedules appointments) 2. Database (on which appointments and medical records are stored) 3. Insurance Claims System (to which our system transmits claims via a standard protocol) 4. The Internet (over which encrypted informa2on is sent)
- 41. CCL – Pillar, System and Boundary
- 42. Requirements Always Emerge It is impossible to know all requirements in advance “Thinking harder” and “thinking longer” can uncover some requirements, but Emergent requirements are those are users cannot iden2fy in advance Every project has some emergent requirements
- 43. So What Do We Do? • We Talk More, Write Less – But write some if you need to • Show SoTware to Users • Acknowledge that Requirements Emerge – And all that this implies • Progressively Refine Our Understanding of the Product – And express this progressive refinement in the product backlog
- 44. Stories Make Great Backlog Items Card • Stories are tradiIonally wriMen on note cards • May be annotated with notes, esImates, etc. Conversa2on • Details behind the story come out during conversaIons with product owner Confirma2on • Acceptance tests confirm the story was coded correctly
- 45. Beat the System There’s usually a beLer role name than “The System.” You may be tempted to have a role “The System,” e.g., System Generates Daily Summary Report Instead, try describing the human who makes use of what the system does: Supervisor Selects Daily Summary Report. It’s even beMer if you can idenIfy what the human is going to do with the result: Supervisor Adjusts Schedule Moving from the domain of informaIon processed in the user’s head back to user acIons can help us focus beMer on the user’s true needs (Don’t force it, though – “The System” may be the most expressive name)
- 46. Humans Only !!! A role can correspond to a human or an automated system. Should roles be filled only by humans, or can we name automated systems? Roles can be either: • We like the role to menIon the human when the human feels like they’re interacIng with the system (even if that interacIon is through another system such as a web browser) • But consider the system boundary (context diagram); if an automated system connects to our system, it’s fine to name that system as the role • For example, out pet sales system “talks” to the bank’s automated credit card processing system, so Credit Card Processor would be a fine role name
- 47. Summary • Roles iden2fy paLerns of usage; different roles interact differently with the system • Don’t forget important roles such as operators, administrators, and auditors • Deepen your understanding of the user by considering their goals, domain and technology experIse, and frequency of use • Use adjec2ves to succinctly idenIfy roles (Go beyond User) • Rather than using System as a role, try to iden2fy who acts and who benefits
- 48. Where are the Details Process mapping, sketching, and storytes-ng help define a story’s details. The heart of a story is the high-‐level funcIonality captured in the headline, but that doesn’t define funcIonality enough to just go implement it Implementa2on requires detailed decisions about how the feature will work, and how we’ll know it’s done User stories don’t come with a built-‐in method for these decisions: Every team is different, and there are many approaches We’ll briefly explore three techniques that many teams have found helpful: Process Mapping, Sketching, and Storytes2ng
- 49. Process Mapping: Follow the Object • Triggers, pulses, and audio are the key objects • This map shows how a trigger goes to a sound generator, and its audio goes to a mixer; the drum clock generates a pulse that goes through a paMern sequencer that drives drum audio, which goes to its own volume control and the mixer; then all audio goes to a master volume control and out to a speaker • One way to figure out should happen is to follow the object; track an object as it moves through – and is transformed by – the system • Consider an electronic keyboard with a built-‐in rhythm secIon where you can set the drummer up with a loud bossa nova, then play your tune on the keyboard What do we find when we map the objects?
- 50. Triggers, pulses, and audio are the key objects This map shows how a trigger goes to a sound generator, and its audio goes to a mixer; the drum clock generates a pulse that goes through a paMern sequencer that drives drum audio, which goes to its own volume control and the mixer; then all audio goes to a master volume control and out to a speaker Modern keyboards work more in the digital domain, but that’s irrelevant to the main point; in process mapping we idenIfy (and devise) the moIon and transformaIon of objects in the system Follow an objet to find its movement through & transforma2on by the system. Keyboard Sound Generator Clock Drum Sound Generator PaLern Sequencer Rhythm Volume Mixer Overall Volume Trigger Audio Pulse Audio Trigger Audio Audio Audio Speaker (Audible Sound)
- 51. Watch the People Watching people gives a different perspec2ve on the value stream (compared to focusing on key objects such as transacIons). Focusing on people lets you ask them several key quesIons: 1. What do you do in the normal case? (This may reveal places the system can ease or eliminate work) 2. Are these special cases or excep2ons that are handled differently? How do they work? (This may reveal process flows you didn’t know about) 3. What else do you do? (This may reveal key objects and opportuniIes you weren’t aware of) Objects usually carry the value, but people give you key insights. A map of the flow of items and the processes that work with them can be a very useful tool.
- 52. Remembrance of Things Past Data-‐intensive systems require details about where to find and store data. • Objects and people are interesIng, but we oqen also need to map the data that’s been remembered by the system • For data-‐intensive systems, working out where to find data is a key challenge • Some feeds, databases, and so on are outside and others inside the system boundary. As usual, our context maMers • The level of detail depends on the stage • In early planning, it’s enough to know “We can get that data somewhere.” For implementaIon, we need details about where the data is and the transformaIons it needs
- 53. StorytesIng Storytests help create the meaning of a story. Storytests are tests in the language of the domain, wriMen to clarify a story They aren’t meant to be exhausIve but to communicate a story’s essence ImplementaIon requires details, but less is needed to understand and esImate stories Tests are not ripe apples on a tree, waiIng to be plucked and used; rather, creaIng tests helps create the meaning of the story What do we do with storytests? Concrete examples are great for helping discuss stories, and are prime candidates for automaIon
- 54. Best Ideas Where do you get your best ideas for func2onality? (Your opinion; there’s no single right answer) Building models of users and/or ac2vi2es Watching users in ac2on (doing their work) Brainstorming, alone or with others Listening to what users tell us they need
- 55. Layout Overall System As you proceed, your pile of stories will grow and you’ll rip up some stories It helps to organize the cards according to some criterion • Theme • Category • Flow • NavigaIon • EvoluIonary Path • Release or IteraIon WriIng headings according to the Role-‐Ac2on-‐ Context formula helps a lot here You can also use paper mockups of screens and flow Organize your stories to reveal the big picture The example on the right shows how a user would navigate in the new applicaIon
- 56. Priori2zing the Product Backlog
- 57. The Product Backlog Iceberg A descripIon of desired funcIonality told from the perspecIve of the user or customer User Story A large user story Epic A collecIon of related user stories Theme
- 58. How Much Detail? Process Fixed Input Must be described in just enough detail to be turned into the output by the process Output Fixed Just-‐in-‐2me just-‐enough
- 59. What Makes a Good Story? Independent I Negotiable N Valuable V Estimatable E Sized Appropriately S Testable T
- 60. • Dependencies lead to problems esImaIng and prioriIzing • Can ideally select a story to work on without pulling in 18 other stories Independent • Stories are not contracts • Leave or imply some flexibility Nego2able • To users or customers, not developers • Rewrite developer stories to reflect value to users or customers Valuable • Because plans are based on user stories, we need to be able to esImate them Es2matable • Small enough to complete in one sprint if you’re about to work on it • Bigger if further off on the horizon Sized Appropriately • Testable so that you have a easy, binary way of knowing whether a story is finished • Done or not done; no “parIally finished” or “done except” Testable I N V E S T
- 61. PrioriIzing the Product Backlog Three Steps Organize Needs into Themes Priori2ze Themes Assess Importance of Each Theme 1 2 3
- 62. Why Themes? OTen Individual Stories Cannot be Priori2zed Against Each Other • The ‘A’ key or the ‘E’ key? • Tables or Undo? • The leq front wheel or the right front wheel? • Increased leg room or a larger engine? What’s More Important in a Word Processor? What’s More Important on a Car? 1 2
- 63. Eliminate redundant stories Write each story on its own note card or post-‐it Label each group with a theme name Group similar stories Review the results If you have a lot of themes or have small themes, consider making themes of themes Steps for Organizing into Themes If you started with a story-‐wri2ng workshop, you may already have themes.
- 64. Affinity Grouping Distribute cards equally to all par2cipants • No parIcular paMern to how you do this Someone reads a card and places in on wall / table • Others look for similar cards and add them to it Next person reads a card, places it, and others place similar cards with it Con2nue repea2ng un2l out of cards
- 65. User Story Template – 1 As a [user role] I want to [goal] • So I can [reason] • As a [type of user] I want to [perform some task] so that I can [reach some goal] Example: • As a registered user I want to log in • So I can access subscriber-‐only content
- 66. User Story Template – 2 • Who (user role) • What (goal) • Why (reason) – Gives clarity as to why a feature is useful – Can influence how a feature should funcIon – Can give you ideas for other useful features – That support the user's goals
- 67.