User Stories considered harmful Why Product Owners and Developers failed at gathering requirements and communication The lost art of analysis and testing scenarios Jakub Nabrdalik Allegro
“As an Editor I want article categories to be updated, when allegro categories are updated, so that articles are still visible on pages” - [PO] How long will that take? - But how exactly should it work? - [PO] I don’t know, that’s why it’s on the grooming.
“User stories: Provide a small-scale and easy-to-use presentation of information, with little detail, thus remaining open to interpretation, through conversations with on-site customers.” “User stories are Invitation to discussion”
“A user story is a promise for a conversation.” (Alistair Cockburn) “User stories: […] remaining open to interpretation, through conversations with on-site customers.”
“You really need to have the people-people, the communicators, the warm and friendly people, who like really want to hug everybody and get you into the community, but that's not everybody. That’s not me.”
So how bad are we? Stackoverflow Global Developer Survey 2018 Depression and Other Common Mental Disorders Global Health Estimates: World Health Organization: 2017 Mental health issues like depression and anxiety are particularly common among our respondents [developers]. In the United States, almost 20% of respondents said they deal with either or both. Mood or emotional disorder (depression, bipolar, etc.) Developers 8.5% | Global population: 4.4% Anxiety disorder Developers 7.8% | Global population: 3.6%
Use cases “Use case flows describe sequences of interactions, and may be worded in terms of a formal model. A use case is intended to provide sufficient detail for it to be understood on its own.”
Alistair Cockburn - Writing Effective Use Cases Title: "an active-verb goal phrase that names the goal of the primary actor" Primary Actor Goal in Context Scope Level Stakeholders and Interests Precondition Minimal Guarantees Success Guarantees Trigger Main Success Scenario Extensions Technology & Data Variations List
Use cases simplified Title: "goal the use case is trying to satisfy" Main Success Scenario - Step by step, what happens Extensions: separately numbered lists, one per Extension - Step by step, ALL the corner cases, errors, bad data, and WHAT should happen
[...] well-specified requirements are as formal as code and can act as executable tests of that code! [Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship]
Story: Returns go to stock In order to keep track of stock As a store owner I want to add items back to stock when they're returned. Scenario 1: Refunded items should be returned to stock Given that a customer previously bought a black sweater from me And I have three black sweaters in stock. When he returns the black sweater for a refund Then I should have four black sweaters in stock. Scenario 2: Replaced items should be returned to stock Given that a customer previously bought a blue garment from me And I have two blue garments in stock And three black garments in stock. When he returns the blue garment for a replacement in black Then I should have three blue garments in stock And two black garments in stock.
Story: Returns go to stock In order to keep track of stock As a store owner I want to add items back to stock when they're returned. Scenario 1: Refunded items should be returned to stock Given that a customer previously bought a black sweater from me And I have three black sweaters in stock. When he returns the black sweater for a refund Then I should have four black sweaters in stock. Scenario 2: Replaced items should be returned to stock Given that a customer previously bought a blue garment from me And I have two blue garments in stock And three black garments in stock. When he returns the blue garment for a replacement in black Then I should have three blue garments in stock And two black garments in stock.
Business analyst + System analyst Typical deliverables: - Functional requirements, i.e. logical data models, use case scenarios, work instructions, reports... - Non-functional requirements - ...
Minimum viable analysis for non obvious features Step 1: Write Behavioural Specifications (plain english), with the customer Step 2: Write BDD scenarios (main and extensions) Step 3: Write down all non-functional requirements Step 4: Design the architecture Step 5: Get comments, ideas & approvals from all devs Step 6: Estimate (get everybody to play blinded poker)
Minimum viable analysis for non obvious features Step 1: Write Behavioural Specifications (plain english), with the customer Step 2: Write BDD scenarios (main and extensions) Step 3: Write down all non-functional requirements Step 4: Design the architecture Step 5: Get comments, ideas & approvals from all devs Step 6: Estimate (get everybody to play blinded poker)
Minimum viable analysis for non obvious features Step 1: Write Behavioural Specifications (plain english), with the customer Step 2: Write BDD scenarios (main and extensions) Step 3: Write down all non-functional requirements Step 4: Design the architecture Step 5: Get comments, ideas & approvals from all devs Step 6: Estimate (get everybody to play blinded poker)
Plans are useless but planning is important Do not expect to design a final solution Expect to eliminate waste and learn Thought experiments are cheaper than coding Refining requirements is a difficult art that you have to study There are many methods of gathering requirements, but POs tend to fixate on user stories, and teams follow them. And this is dangerous.
[email protected] @jnabrdalik If your only tool is a hammer, every problem looks like a nail User Stories are great for discussions, but that’s about it Allegro
istanbultechtalks
masumitsu
zoetrope
yuhei_fujita
mackee
yuya4
codehex
gpsnmeajp
kubode
uhooi
napplecomputer
koluku
stephaniewalter
jrom
sugarenia
searls
pedronauck
chrisshort
destraynor
bkeepers
hatefulcrawdad
swwweet
holman
garrettdimon