Waarom investeren product owners in een upfront “wat” omschrijving?

[DRAFT]

We kennen de aanbeveling om user stories te schrijven in het format “als [wie?] wil ik [wat?] kunnen opdat ik [doel?]”.

Maar deze aanbeveling vermeldt niet dat product owners upfront tijd moeten investeren om de “wat” in een user story te beschrijven, nog voor refinement met het team is gestart. Is het een vorm van inefficiënt en overbodig upfront design? Hebben we hierbij contra-productieve risico’s?

Soms kan het wel efficient zijn om al vroeg oplossing opties te overwegen. Maar is er naast die meerwaarde, ook andere impact? Is het nuttig om die opties ook op te schrijven? En hoeft dit dan in een user story (titel)?

Hier volgen enkele kritische bedenkingen bij het idee om upfront helemaal geen “wat” meer te beschrijven in user stories.

Bad smells

Misschien herken je een of meerdere van deze signalen, die een onderliggende root cause kunnen verhullen?

  • De user stories in een backlog bevatten soms alleen de “wie” en de “wat”, maar de “opdat” of “zodat” (het doel) ontbreekt. Dit format is ook geen officiële scrum standaard: Ken Schwaber, Jeff Sutherland, Scott Ambler en zelfs Mike Cohn wijken hier bijvoorbeeld vaak van af. (voorbeelden achteraan deze blog).
  • Je hebt een technische achtergrond of veel product ervaring. Die stellen je als product owner in staat om heel ver met je team mee te redeneren over oplossingen. Dat is een voordeel, maar de verleiding is ook groot om dit onbewust te veel en te vroeg te doen, of om suggestief te worden. Nochtans wil je ergens wel de creativiteit van jouw team alle kansen gunnen. De verleiding is gewoon groot, en het gebeurt vaak onbewust.
  • Vervelend: je business stakeholders formuleren (steeds weer) oplossingen, ipv business vragen te stellen. Eigenlijk voed je dit door de vroege focus op “wat”. Met die focus durft het namelijk moeilijker te worden om value en backlog-volgorde toe te kennen, omdat die business value een afgeleide is van de nood of meerwaarde die wordt ingevuld, niet van de aard of techniciteit van de oplossing.
  • Heeft je team je al aangesproken in een retrospective met “Vraag ons voortaan om oplossingen te bedenken en bouwen voor onze stakeholders, vraag ons niet meer om jouw oplossing te maken”. M.a.w. geef ruimte aan onze creativiteit.
  • Wordt jouw team passief op momenten dat ze creatief zouden moeten zijn? Wanneer hebben ze jou laatst verrast met een onverwachte out-of-the box oplossing die je zelf niet had kunnen bedenken?
  • Of ben je al een stap verder, is jouw team er al gewoon aan geworden dat je oplossingen voorkauwt. Je krijgt misschien zelfs feedback dat je te weinig concreet bent bij de minste onduidelijkheid in de beschrijving van jouw oplossing (in hun perceptie).
  • Epic en story refinements durven vervelende en inefficiënte momenten te kennen als je jouw voorbereidend werk vaak grondig moet aanpassen of als je te vaak user stories moet weggooien*: dat gebeurt namelijk vaker met beschrijvingen van oplossingen, dan met noden of probleem omschrijvingen. Je wordt meer dan nodig geconfronteerd met kritische vragen van je team over de relevantie van je stories.
  • Nog erger: je krijgt geen kritische vragen van je team. In het beste geval krijg je dan vervelende feedback over prioriteiten en product relevantie van je stakeholders bij een sprint review.
  • Of je gaat al door de ergste nachtmerrie: je blijft opleveren zonder kritische vragen, en de relevantie en meerwaarde van je team of van je project daalt.

* Een epic of user story veranderen of weggooien is natuurlijk niet noodzakelijk slecht. In tegendeel: we passen onze backlog liefst vroeg en snel aan als dat nodig is. Maar we willen dit natuurlijk voorkomen als het niet nodig is, en als het vaak voorkomt kan het aangeven dat er een onderliggende oorzaak is.

De tip: schrijf geen “wat” op voorhand.

Als je wil voorkomen dat je oplossingen zelf bedenkt, schrijf er dan geen.

Herken je een of meerder van de bad smells? Dan kan je experimenteren met de tip in deze blog. We vermelden hier trouwens enkel de context van user stories, maar de logica is ook van toepassing op grotere scope levels zoals epics, projecten, missies.

Schrijf dus geen “wat” lijn, of vervang de “wat” door een vaste formulering, bijvoorbeeld “een oplossing”. Concreet krijgen we dan zulke formats:

Als [wie?]
wil ik een oplossing
om [doel?]

Bij de refinement oefeningen met je team kan je dan samen met je team de oplossing kort benoemen en de user story aanpassen.

Voordelen

voor iedereen

  • De eerste versie van je epic/user story is korter, bondiger, gemakkelijker te verstaan.
  • De backlog wordt korter en overzichtelijker.

voor jezelf als product owner

  • Zonder suggesties over de “wat” word je efficiënter omdat je er op voorhand geen tijd in hoeft te investeren.
  • Met alleen de aandacht voor “wie” en “waarvoor” heb je een vroege verhoogde focus op de relevantie.
  • In je backlog kan je in 1 oogopslag de backlog items herkennen waar de letterlijke tekst “een oplossing” staat ipv een omschrijving, en voor welke user stories je nog refinement nodig hebt.

voor jouw business stakeholders

  • Jouw communicatie met stakeholders over user stories wordt bondiger en efficiënter.
  • Je helpt ook je business stakeholders om mee te reflecteren over hun noden en business value, ipv over oplossingen.
  • Je verhoogt de het gevoel van betrokkenheid van je business stakeholders, die de “zodat” vaak gemakkelijker begrijpen omdat dit hun business nood of doel omschrijft, en makkelijker in business taal te formuleren valt.
  • Je kan beter en gemakkelijker volgorde en prios toekennen aan je product backlog items.

voor jouw team

  • Je houdt bij het aanbrengen van een nieuwe story  de focus voor je team op het doel.
  • Je vermijdt meer dat je onderweg struikelt over een verschillende interpretatie van de oplossing, als het team die zelf mee formuleert.
  • Je toont respect voor je team door hen vroeg en minder suggestief te betrekken bij de zoektocht naar oplossingen. Deze werkwijze geeft alle ruimte om je te laten verrassen met betere oplossingen die je zelf kon bedenken.

Nadelen / Waarom niet?

De meest evidente reden die ik nu kan vermoeden om toch zelf extra te investeren in een beschrijving van de oplossing is directe efficiëntie. Achterliggende redenering: Als jij zelf best oplossingen kan bedenken en beschrijven, waarom zou je dan jouw team daar nog tijd mee laten verliezen?

De lange lijst bad smells en de vele voordelen van deze vereenvoudiging laten vermoeden dat hier een gevaar voor zelf overschatting schuil gaat. Er is ook risico op gemiste expertise groei in het team. Maar laten we niet blind of dogmatisch zijn, en kritisch op zoek gaan wanneer zo’n korte termijn efficiëntie nuttiger kan zijn.

Zou het kunnen renderen bij een tijdelijk team, of op het einde van een project waarbij de investering van de leercurve niet meer kan renderen? Of kan deze korte termijn efficientie tijdelijk nuttig zijn als de opleverdruk heel groot is?

Misschien wel. Maar dan is het belangrijk om ook kritisch de tijdelijke duur van het team of de duur van de opleverdruk te benoemen en bewaken, want ergens is er een grens.

De “kleinste” oplossing aub.

We werken graag iteratief en incrementeel, en daarom gaan we graag op zoek naar een eerste kleinst werkende stap die ons stapsgewijs inzicht geeft in een uiteindelijke oplossing. We vertrouwen erop dat deze aanpak ons kan leiden tot onverhoopt betere producten en oplossingen dan door onmiddellijke analyse. De verleiding is echter groot om te snel een meer omvattende oplossing te bouwen.

Om die alertheid continu te voeden, kunnen we spelen met nuances in de vaste formulering: we kunnen “oplossing” ook letterlijk vervangen door “de kleinste oplossing”, of “een kleinst werkende stap”.

Als [wie?]
wil ik de kleinst werkende stap
om [doel?]

Geen “why” is niet zo vreemd

The Scrum Guide van Ken Schwaber en Jeff Sutherland  zegt eigenlijk niets over het formaat van User Stories.

Scott Ambler geeft in “User Stories: An Agile Introduction” de “why” als optioneel aan.

Mike Cohn vermeldt helemaal geen “why” in User Stories and User Story Examples, maar in User Stories Applied: For Agile Software Development beveelt hij dit wel aan.

Ik vond geen aanwijzingen dat de “why” gelijktijdig moet geschreven worden.

Next steps

Geen enkele tip is een silver bullet die voor iedereen en altijd geldt of belangrijk is.

  • Schat eerst in of er een meerwaarde voor jou in zit.
    Indien niet, wil je jouw goede motivatie in een comment bij deze blog tovoegen zodat we er allemaal uit kunnen leren?
  • Indien wel, bedenk enkele nuttige metrics hoe je kan meten of een dergelijke manier van werken je team of jouw rol in het team verbetert.
  • Doe het: experimenteer ermee zodat je kan zien of het impact heeft. Communiceer er wel op voorhand over met jouw team, zodat zij niet verrast worden bij een volgend refinement. Je wil namelijk geen beeld van een luierik opwekken.
  • Check of dit inderdaad de impact heeft die je voor ogen had. Als je geen harde metrics kon bedenken, betrek collega’s om feedback te geven en voorkom dat je jezelf moet inschatten.
  • En niet vergeten: celebrate & be happy als je kan vaststellen dat het helpt, of stuur bij. Deel jouw learnings (hier) met de buitenwereld!

Help je collega’s en laat hier weten of je dit een nuttige tip vindt. Heb je dit al in de praktijk gebracht, of heb je suggesties?

Good luck!

to do, dit blog artikel:

  • referenties en opzoek materiaal en links aanvullen
  • artikel moet leuker presenteren: keywords aanduiden, links aanvullen, image(s) toevoegen
  • pre-reviewers aanspreken?
    voorstel: reviewers op blog vermelden die fb geven?,
    fb gevers mee prio laten kiezen voor volgend topic?
  • drawing (filmpje toevoegen)
  • vertaling > eng

To do, blogsite:

  • scrum methodologie pages op deze blog vervangen door links naar de officiele guide
  • blogsite image veranderen ? + kleine profiel foto
  • email subscription toevoegen (?mailchimp)
  • links > ilean
  • social sharing
  • copywriter aanspreken?