Er wordt ontzettend veel gezegd en geschreven over Scrum, maar hoe je in een Scrum omgeving met requirements omgaat, komt onvoldoende uit de verf.
Wij krijgen er althans voortdurend vragen over van analisten en product owners. Om daar voor eens en voor altijd antwoord op te geven, heeft Nicole een nieuw boek geschreven met de titel Requirements in Scrum – Ontdek hoe je businesswaarde creëert.
Weet jij bijvoorbeeld waar Scrum in essentie om draait? In onderstaande afbeelding vind je het antwoord dat daarop in het boek Mastering Professional Scrum (aanrader) gegeven wordt.
Wij vinden het zo krachtig verwoord dat we het als quote hebben opgenomen in ons gratis e-book met 52 Agile requirements tips & inspirerende quotes. Mocht je het e-book nog niet hebben, download het dan hier. Gratis en voor niets!
Requirements in Scrum
Het nieuwe boek is speciaal voor analisten geschreven. Het laat zien hoe je de echte requirements vindt en ‘how to deliver higher value more frequently’.
De kern van ons vak is immers niet veranderd, maar de manier waarop je te werk gaat des te meer. In het boek ontdek je welke principes, richtlijnen en tools Scrum je daarvoor aanreikt.
In dit boek ontdek je hoe Scrum je helpt veel businesswaarde te creëren, door:
- Iedereen met de neus dezelfde kant op te richten
- De ontwikkelaars niet teveel maar ook niet te weinig details te geven
- Flexibel in te spelen op wijzigingen
- Niet te vroeg in oplossingen te denken
- Aannames systematisch te verifiëren
Tijdens het schrijven van het boek stelden we onder dit artikel de volgende twee vragen:
- Wat mis je nog in bovenstaande lijst? Wat zou je in het boek willen lezen?
- Welke van de 6 punten spreken je het meest aan? En welke het minst?
Naast de antwoorden die per e-mail binnenkwamen, ontvingen we ook reacties onder dit artikel. Iedereen die daartoe de moeite heeft genomen, willen we nogmaals hartelijk bedanken.
Nicole de Swart & Priya Soekhai
Hoe je uiteindelijk met de requirements tot een echt product komt, in een agile omgeving. Dus o.a. de product visie en relatie met de requirements.
Oké Marcel, dit gaat zeker aan bod komen in het boek. Bedankt voor je reactie.
Hoe houd je de software consistent wanneer er geen uitgewerkt design beschikbaar is? Tijdens refinement sessies kunnen teamleden zich uitleven in detailvragen en ideeën. Al naar gelang de discussie komt er dan een uitkomst. Op een ander moment zou de discussie tot een andere uitkomst kunnen leiden.
Dat is een hele goede vraag. Ga ik iets mee doen.
Ik denk dat dit niet alleen een heel goede vraag is, het lijkt mij zelfs de hamvraag te zijn. Het voortraject voor we een product backlog opstellen, voor we met de lijst aan requirements beginnen, is essentieel. Doe dit niet zorgvuldig genoeg en de waarde zal blijven steken op een te laag niveau, of je het nu agile doet of niet.
Dingen die in dit verband nuttig kunnen zijn: Disciplined Agile Delivery of DAD dat vooral de business kaart trekt en anderzijds dual track agile, spint 0 en dergelijke die de menselijke kant in de verf zetten. Als beide niet goed zijn afgedekt, wordt het een mislukking en de de aanpak (bv agile versus waterval) zal daar omzeggens niets aan veranderen.
Ik sluit me aan bij de vorige vragen. Ik zie ook dat er een soort wildgroei aan oplossingen ontstaat omdat het team de oplossing die ze op dat moment het beste lijkt, kiezen (vaak zonder te kijken hoe een zelfde soort probleem in het verleden is opgelost). Je wilt in een organisatie die met standaardproducten werkt ook dat bepaalde acties in de software altijd op een zelfde manier worden uitgevoerd. En dan gaat het juist om de details. De ervaring lijkt me te leren dat ik requirements meer in detail moet uitwerken.
Dus ik ben erg geïnteresseerd in punt 2 van de lijst!
Yvonne, werk je dan requirements meer in detail uit of ben je een oplossing aan het voorschrijven? Let op dat je niet op de stoel van de ontwikkelaars gaat zitten, maar blijf gefocust op de business.
Als het team een wildgroei laat ontstaan en niet kijkt naar eerdere oplossingen, moeten ze daar vanuit IT (?) op aangesproken worden. Eventueel iets over opnemen in Definition of Done. Laat ze vooral zelf aangeven wat ze eventueel nodig hebben om hun verantwoordelijkheid op te pakken. Hopelijk heb je geen traditionele ontwikkelaars die alleen bouwen wat gespecificeerd staan in het agile team zitten.
Weet niet of het wat brengt, maar gooi het toch hier in. Ik merk dat ik altijd een ketting van stories heb. Het start met een design voor een feature, dan moet de backend story de data leveren en dan de frontend story die het een en ander bij elkaar brengt. Als je geen dependencies wilt (disk) ben je dus voor elke feature zo 3 sprints nodig.
Een ander punt is dat er zoveel gebeurt in het process, dat veel ideeen boven komen en die ik dan tot nog toe snel in een story gooi, in een apart “bakje” – die moeten ergens terug naar epics en langs de meetlat van productfeatures/moet het nu/wat levert het op – komen. Dat is een kunst op zich.
Weet niet of ik voor je boek of topic ga, dan eenvoudig negeren. ben zoekende en erg nieuwsgierig naar jullie nwe boek
Het is meer een onderwerp voor een boek over de user story techniek, maar ik kan je wel een paar tips geven.
Backend en frontend stories wijst erop dat je denkt vanuit de techniek of vanuit de werkzaamheden van het team. Laat dat los en ga denken vanuit de gebruiker. Hanteer het businesswaarde-criterium voor het onderkennen van user stories. De SPIDR-techniek kan je daar wellicht bij helpen (zie de blogartikelen https://www.reaco.nl/blog/user-stories-te-groot-gebruik-de-spidr-techniek/)
Je 2e alinea beschrijft een Bottom up proces. Ik zou er een top down proces van maken. Daarmee bedoel ik: Begin bij het businessdoel en de productvisie, focus vervolgens alléén op de features en user stories die daarvoor cruciaal zijn, negeer(!) de rest voor ’the time being’. Een impactmap kan je hierbij structuur geven https://www.reaco.nl/blog/impact-map-voor-user-stories-met-businesswaarde/. En dit blogartikel helpt wellicht ook https://www.reaco.nl/blog/hoe-bepaal-je-businesswaarde-van-user-story/.
Succes met je zoektocht, Harry.
Mooi voornemen jullie boek. Ik zie ernaar uit.
Hier mijn pennies.
– Hoe om te gaan met externe partijen die nodig kunnen zijn in het definiëren en realiseren van requirements/stories, bv een IT servicedesk of ketentest partner.
– Hoe je requirements op de juiste wijze formuleert.
– Hoe je het empirisch houdt en voorkomt dat je toch gaat watervallen.
– Hoe je als PO en “devs” in een scrum team met de klant requirements formuleert, zonder dat je de traditionele requirements- of businessanalysten beschikbaar hebt.
– Hoe dat gebeurt in een refinement sessie (of niet).
– Verschil tussen acceptatie criteria en definition of done.
– Waarom je geen definition of ready zou willen in scrum.
Succes!
Ontzettend bedankt Ronald. Hier kan ik wat mee.
Mogelijke aanvullingen zijn:
User stories zijn volgens mij niet compleet zonder acceptatie criteria. Of te wel hoe verrijk je user stories met adequate acceptatiecriteria? Of hoe pas je “Specification by example” en/of “Test driven design” toe in combinatie met user stories?
Hoe beoordeel je user stories. Welke (automatische)hulpmiddelen staan er tot je beschikking voor het reviewen en beoordelen van user stories en user stories verzamelingen. Ik kom veel “checklists” tegen op internet, die je handmatig moet toepassen en dus veel tijd vergen, maar ook veel tools die de kwaliteit van user stories automatisch analyseren. Dit gaat verder dan verplichte velden invullen in backlog tools.
Punt 2 is voor mij een belangrijk punt. En hoe ga je om met voortschrijdend inzicht en speel je flexibel om met wijzigingen in samenhang met punt 2.
Zeker een interessant boek. Het is en blijft het lastigste onderdeel binnen Scrum. Heb je de intentie om het boek ook in het Engels te gaan publiceren? Dan kan ik het onder mijn collega’s gaan promoten, die hier erg mee worstelen.
Leuk te horen dat je het boek interessant vindt, Kor. Vooralsnog heb ik geen plannen om het boek te laten vertalen. Mocht dat veranderen dan laat ik het weten.