1
Life Cycle of User Story:
Why BDD matters to PM/PO?
Ravi Tadwalkar, Enterprise Agile Coach & Community Evangelist, Cisco...
2
A User Story is a brief statement of intent
that describes something the system needs
to do for the user
“The user story...
3
• Product Owner writes the
user stories with input from
customer, stakeholders,
and the team
• SME (Team member) with
do...
4
• Effective communication is the key and
we need a common language
In agile development, the developer must
speak the la...
5
• User story is not a detailed requirement
• User stories are not detailed upfront
but are elaborated just-in-time
• So ...
6
• 2-3 sentences used to
describe intent of the story
• Summarizes intent and
represents a more detailed
requirement, who...
7
As a [role]
I want [feature]
so that [benefit]
Scenario 1: [scenario title]
Given [initial context]
When [event occurs]
...
8
As a [role]
I want [feature]
So that [value]
Acceptance Criteria
Scenario 1
Scenario 2
Scenario 3
Scenario 4
Scenario 5
...
9
• Rule of thumb: get the most value with the minimum effort
Choose the split that leads to the biggest difference in val...
10
Please pre-load this cheat-sheet with sample user stories from your existing product backlog.
Put those sample stickies...
11
Please pre-load this cheat-sheet with sample user stories from your existing product backlog.
Put those sample stickies...
12
Work Complexity Risk Points
Small Small Small 1
Small Small Medium 2
Small Small Large 5
Small Medium Small 2
Small Med...
13
14
• I – Independent
To schedule and implement them in any order
• Stories are valued independently meaning each story can...
15
Product Owner PO+ARCH+REP PO+QA+REP PO+Team
Product Owner
writes epic stories
that are negotiable
and has relevant
busi...
16
Product Owner PO+Coach PO+ARCH+REP
User stories are not
properly written
Written as software
requirements,
functional s...
Time to do some exercise on easel sheets-
(Remember “over 8 no collaborate”, quote from Luke Hohmann)
Let’s try this in sm...
Upcoming SlideShare
Loading in …5
×

Life cycle of user story: Outside-in agile product management, or “Why BDD matters to PM/PO?"

3,689 views
3,205 views

Published on

It has always been my pleasure and fun to facilitate workshops for PM (product management) community at and outside Cisco, although this was first time I did a BDD workshop with PMs alone. And I realized today how PayPal has been a really great venue for SVPMA annual product camp "unconference" for 1k+ PMs with 550 waitlisted this year! I look forward to this event every year now...huge success!
Synopsis: As PMs, we should be driving innovation thru' those fuzzy ideas in terms of scenarios you always think about. Talk about those to your engineering teams or even peer PM/POs, and you see those diverging ideas converging to something concrete. That's how BDD helps you shape that idea. That fuzzy scenario, when validated thru' an engineering "spike", can be useful for your MRD/PRD/use-case-models/stories...whatever it is that you want to use to drive the product development. Go for it! So instead of doing top-down or bottoms-up product management, try this inside-out approach.
My workshop on BDD is about what I term as "Outside-in agile product management". To understand what I really mean by that, here is my slideshare presentation used rarely when teaching from the back of the class during this hyper-interactive workshop.

Published in: Business

Life cycle of user story: Outside-in agile product management, or “Why BDD matters to PM/PO?"

  1. 1. 1 Life Cycle of User Story: Why BDD matters to PM/PO? Ravi Tadwalkar, Enterprise Agile Coach & Community Evangelist, Cisco Systems June 2012
  2. 2. 2 A User Story is a brief statement of intent that describes something the system needs to do for the user “The user story is a lightweight and more nimble substitute for what has been our traditional means of specifying software requirements – software requirement specifications and use cases…” Dean Leffingwell, Creator of SAFe (Scaled Agile Framework)
  3. 3. 3 • Product Owner writes the user stories with input from customer, stakeholders, and the team • SME (Team member) with domain expertise can also write user stories • However, it is up to the product owner to accept and prioritize these potential stories into the product backlog • User stories focus the work on the value defined by the user rather than a functional breakdown structure • User stories provide a lightweight and effective approach to managing requirements for a system • Details of system behavior do not appear in the brief statement • 3 C’s or user stories- card, conversation & confirmation Story is written on a Card and is groomed through conversations between team and product owner that lead to confirmation about acceptance criteria.
  4. 4. 4 • Effective communication is the key and we need a common language In agile development, the developer must speak the language of the customer, not the other way around • The user story provides the common language to build understanding between the user and the technical team Bill Wake, XP guru, creator of “cake slicing” technique
  5. 5. 5 • User story is not a detailed requirement • User stories are not detailed upfront but are elaborated just-in-time • So they are short and easy to read • User stories are not carried in large unwieldy documents but are ordered lists • User story and related code serve as inputs to documentation • User stories represent small increments of valued functionality • User stories are easy to estimate • User stories need little/no maintenance • User stories can be safely discarded or archived after implementation of “spike”
  6. 6. 6 • 2-3 sentences used to describe intent of the story • Summarizes intent and represents a more detailed requirement, whose details remain to be determined (which leads to…) • Recurrent discussion between the team, customer, product owner, and other stakeholders • Attached to a user story as notes (which solidify…) • represent the conditions of satisfaction • Written as scenarios
  7. 7. 7 As a [role] I want [feature] so that [benefit] Scenario 1: [scenario title] Given [initial context] When [event occurs] Then [ensure some outcomes] Scenario 2: [another scenario title] Given [initial context] And [another context] When [event occurs] Then [ensure some outcome] And [ensure another outcome]
  8. 8. 8 As a [role] I want [feature] So that [value] Acceptance Criteria Scenario 1 Scenario 2 Scenario 3 Scenario 4 Scenario 5 Notes: [discussion notes] US.01 As a [role] I want [feature] So that [value] Acceptance Criteria Scenario 3 Scenario 4 Notes: [discussion notes] US.01.01 As a [role] I want [feature] So that [value] Acceptance Criteria Scenario 5 Notes: [discussion notes] US.01.02
  9. 9. 9 • Rule of thumb: get the most value with the minimum effort Choose the split that leads to the biggest difference in value. Choose the split that leads to the smallest difference in size • Patterns for Decomposing Features into user stories 1. On operation boundaries 2. On business rules 3. On effort boundary 4. On complexity 5. On data types 6. On input methods 7. On requirement type 8. On workflow boundaries 9. On engineering activity 10. On architectural boundaries - this is your last resort, when nothing else works! Here are 10 examples of patterns for feature decomposition into vertically sliced user stories: Please pre-load this cheat-sheet with sample user stories from your existing product backlog. Put those sample stickies next to each decomposition pattern here!
  10. 10. 10 Please pre-load this cheat-sheet with sample user stories from your existing product backlog. Put those sample stickies next to each decomposition pattern here! Pattern Original story Split stories Identify operational boundaries I'd like to manipulate posts on wiki  I'd like to edit a post  I'd like to share a post  I'd like to delete a post Identify independent business rules I'd like to search for a post  I'd like to find posts from a specific person  I'd like to find posts sent or received in a specific date range  I'd like to find posts pertaining to a certain topic  I'd like to find posts linking to a certain post Perform what-if analysis to account for technical or scheduling dependencies and identify an effort boundary I'd like to see an up-to-date contact list in chat window  I'd like to see an up-to-date contact list in my chat window: o need to poll server periodically o When notifications are implemented, we can leverage API Isolate the simple from the complex I'd like to share knowledge and information with others  I'd like to quickly share mostly text and maybe a link, a-la Twitter  I'd like to add embedded images and multimedia content to my posts  I'd like to add references to external data to my post, updated on-the-fly Handle various data types separately whenever possible I'd like to ignore updates I am not interested in  I'd like to ignore updates from a specific person  I'd like to ignore updates in a specific community
  11. 11. 11 Please pre-load this cheat-sheet with sample user stories from your existing product backlog. Put those sample stickies next to each decomposition pattern here! Pattern Original story Split stories Provide the user with different ways to input data into the application I'd like the application to help me with the list of users I'm sharing a post with  I'd like to be able to pick people from a list of contacts I'm most often in touch with  I'd like to be able to search for people in the corporate directory  I'd like the application to auto-complete a person's name as I am typing it. Separate functional and non-functional requirements I'd like to be able to attach files to a post  I'd like to be able to attach multiple files to a post. It's OK if I have to add each one separately.  I'd like an easy way to attach multiple files to a post. Multiple select, drag-and-drop or any other form is acceptable so long as I don't have to add each file separately. Identify workflow boundaries I'd like the system to assist me in creating a post  When I add a post title, I'd like the system to look for similar posts and give me an option to comment or edit them instead so as to avoid effort duplication  I'd like to link data from other posts into the post I am creating and have the system update it automatically Split out the research from the implementation I'd like to configure the application to my own taste  As an engineer, I need a framework to handle user preferences so that I can make certain aspects of the application configurable  As a user, I'd like to be able to set user preferences in order to configure the application the way I like it
  12. 12. 12 Work Complexity Risk Points Small Small Small 1 Small Small Medium 2 Small Small Large 5 Small Medium Small 2 Small Medium Medium 3 Small Medium Large 5 Small Large Small 3 Small Large Medium 5 Small Large Large 8 Work Complexity Risk Points Medium Small Small 3 Medium Small Medium 5 Medium Small Large 13 Medium Medium Small 5 Medium Medium Medium 8 Medium Medium Large 20 Medium Large Small 8 Medium Large Medium 13 Medium Large Large 20 Work Complexity Risk Points Large Small Small 8 Large Small Medium 13 Large Small Large 20 Large Medium Small 13 Large Medium Medium 20 Large Medium Large 20 Large Large Small 20 Large Large Medium 20 Large Large Large 20 Facilitators recommend that teams should use “user story sizing board” together with this cheat-sheet. Please pre-load the cheat-sheet with sample user stories from your previous release, specific ones for your team. New teams can use their domain to define what small work is for their specific context. There is “no one size fits all”.
  13. 13. 13
  14. 14. 14 • I – Independent To schedule and implement them in any order • Stories are valued independently meaning each story can deliver value independently • Strive to eliminate 0-valued technical/functional dependencies • Eliminate dependencies by intelligently splitting stories • N – Negotiable Details co-created by customer & team during development • A User Story is not a contract for specific functionality • Flexibility through vagueness • Lack of overly constraining and too-detailed requirements enhances teams and businesses ability to make tradeoffs between functionality and delivery dates • V – Valuable Making each vertical slice through architecture valuable to the customer supports pay-as-you-go attitude toward infrastructure • Create stories that are vertical slices of value to the user • Developers often have an inclination to work on only one layer at a time and “get it right”  WRONG BEHAVIOR • E- Estimable Sizing helps the customer rank & schedule story's implementation • If a user story is too large to estimate, it should be split into smaller stories • If a user story is too uncertain to estimate, then a technical or functional spike story can be used to reduce uncertainty • Estimating user stories draws out any hidden assumptions, missing acceptance criteria, and clarify a shared understanding of the story • S- Small Details can be elaborated through conversations with customer • Small user stories provide more agility and productivity through increased throughput and decreased complexity • T- Testable Decide whether goal of the story is met by writing the tests early • Stories don’t get into an iteration if they can’t get out • Framing stories with clear boundaries will help the team and the business share expectations of the output and avoid big surprises
  15. 15. 15 Product Owner PO+ARCH+REP PO+QA+REP PO+Team Product Owner writes epic stories that are negotiable and has relevant business value Negotiable Valuable Independent Small Estimable Testable Architect and Team Representative negotiate with PO to create vertical slices of large stories along architectural layers, to shape small and independent stories QA ensures stories are testable and estimable with scenarios for each user story Additional story split along scenarios and acceptance criteria may occur Team receives well packaged user stories Team negotiates user stories with the Product Owner Team sizes story for understanding and provides estimate
  16. 16. 16 Product Owner PO+Coach PO+ARCH+REP User stories are not properly written Written as software requirements, functional specs, horizontally sliced Coach will aid Product Owner in writing good user stories PO then journeys on the typical user story life cycle path mentioned earlier with the coach optionally shadowing the meetings
  17. 17. Time to do some exercise on easel sheets- (Remember “over 8 no collaborate”, quote from Luke Hohmann) Let’s try this in small teams of upto 8 folks: 1. Take 1 feature/EPIC 2. Slice the cake 3. Write 1st slice as user story 4. Think of acceptance criteria 5. Write 1st acceptance criteria in english/pidgin ;-) 6. Write that same acceptance criteria using BDD template!

×