De Agile Analist. Ebook over requirements en agile. Deel II

De Agile Analist Ebook over requirements en agile Deel II

2 Inhoud Deel I... 3 1 Inleiding... 3 2 Just in time requirements... 3 3 Just enough requirements... 3 Deel II... 4 4 Samenwerken met de business... 4 4.1 De product owner... 4 4.2 Requirements producten... 5 4.2.1 Productvisie... 6 4.2.2 Product backlog... 7 5 User stories... 9 5.1 Wat zijn user stories?... 9 5.2 User stories of use cases... 10 5.2.1 Use cases 2.0... 11

3 Dit ebook is geschreven voor requirements analisten die in een agile/scrumproject (gaan) werken. Hoewel Scrum geen requirementsfase kent en de analistenrol niet expliciet onderscheid, spelen requirements een cruciale rol in agile/scrumprojecten. In dit ebook lees je hoe succesvolle agile projecten omgaan met requirements. Je zult in dit ebook geen uitleg van het Scrumproces of van de basisprincipes van agile vinden. Ik ga ervan uit dat enige kennis van agile en Scrum en de belangrijkste Scrumtermen bekend zijn. Mocht dat niet het geval zijn bekijk dan even de filmpjes in het Requirements Kenniscentrum en lees de officiële Scrum Guide van Jeff Sutherland en Ken Schwaber. Deel I In het eerste deel van dit ebook lees je wat agile requirements anders maakt dan traditioneel Requirements Engineering. Deel I bevat de hoofdstukken: 1 Inleiding Agile en Scrum zijn in korte tijd populair geworden, maar voor welke type projecten is het eigenlijk geschikt? Wat is het verschil tussen een iteratieve en incrementele werkwijze? 2 Just in time requirements In traditionele ICT-projecten stellen business/informatieanalisten de requirements op tijdens een requirementsfase. In agile en Scrum komt geen requirementsfase voor. Het achterhalen van de requirements wordt zo lang mogelijk uitgesteld. 3 Just enough requirements Agilisten praten over precies genoeg requirements om aan te geven dat er niet te veel requirements mogen worden uitgewerkt. Dit is in tegenstelling met het traditionele Requirements Engineering waarin juist naar volledigheid van de requirements gestreefd wordt.

4 Deel II 4 Samenwerken met de business De ineffectieve WIJ ZIJ cultuur tussen het IT-team en de business die vaak ontstaat in traditionele omgevingen, probeert agile te doorbreken door een intensieve samenwerking en door de business de volledige controle te geven over het WAT en de IT ers over het HOE. 4.1 De product owner Scrum onderkent slechts drie rollen: het ontwikkelteam, de product owner en de Scrummaster. De rol van product owner is een nieuwe, nog niet bestaande rol. Hij komt gedeeltelijk overeen met de volgende traditionele rollen: Business-/informatieanalistnalist v.w.b. het achterhalen van de requirements en deze overbrengen aan het ontwikkelteam. Projectmanager v.w.b. verwachtingsmanagement naar buiten toe en het wegnemen van obstakels (impediments) die de voortgang van het team negatief beïnvloeden. (Product)manager v.w.b. het volgen van de markt, uitdragen van de visie, managen van de roadmap en het voorbereiden van de ingebruikname van de releases. De product owner is verantwoordelijk voor het succes van het product (IT- systeem) en het maximaliseren van de Return on Investment (ROI). Hij bepaalt welk product gebouwd wordt en waar de prioriteiten liggen. De product owner heeft dus het stuur in handen. Een goed functionerende product owner is essentieel voor het!"#$%&'($)$*+,-./0'$,-12345'*6$*789$'/'*6$* Een goed functionerende product owner is essentieel voor het succes van het project. Product owner is een uitdagende rol die om fulltime inzet vraagt. De product owner managet de verwachtingen en stemt af met enerzijds de business en anderzijds de IT-organisatie. Hij is het aanspreekpunt over de inhoud van het te realiseren systeem. De product owner opereert zowel op strategisch als op tactisch niveau: Strategisch Op strategisch niveau houdt de product owner zich bezig met het creëren en uitdragen van de productvisie, het volgen van de marktontwikkelingen en het managen van de roadmap.

5 Tactisch Op tactisch niveau plant hij de release, onderhoudt de product backlog en neemt deel aan de Scrummeetings. Hoewel de product owner als enige verantwoordelijk is voor het maximaliseren van de business value, hoeft hij niet alles alleen te doen. Hij werkt juist intensief samen met het ontwikkelteam, de Scrummaster en met de stakeholders in de business. De product owner weet wat er speelt en stemt met alle partijen af zodat hij de juiste beslissingen kan nemen. Het plaatje hieronder van Roman Pichler, auteur van Agile Product Management with Scrum, vat de werkzaamheden van de product owner kernachtig samen. Tijdsbesteding De product owner heeft ongeveer 50% van zijn tijd nodig om het ontwikkelteam inhoudelijk aan te sturen. Hij bereidt de Sprint Planning Meeting voor, onderhoudt samen met het team de product backlog, beantwoordt vragen en geeft feedback op de gebouwde software. De andere 50% van zijn tijd heeft de product owner nodig voor afstemming met de business en al haar stakeholders. Hij moet allerlei belangen tegen elkaar afwegen, weten wat er speelt binnen de organisatie en de markt, alsmede de stakeholders voorbereiden op de aankomende release. 4.2 Requirements producten Hoewel agilisten niet meer documenteren dan noodzakelijk is, worden in Scrum twee belangrijke producten op het gebied van requirements aanbevolen. Deze producten zijn geen doel op zich, maar zijn belangrijke hulpmiddelen bij het overdragen en inzichtelijk maken van de requirements.

6 De volgende twee producten zijn voor ieder agile-project aan te bevelen: 1. De productvisie 2. De product backlog Hoewel de product owner verantwoordelijk is voor de requirements en daarmee ook voor deze requirementsproducten, spelen het ontwikkelteam en de business stakeholders daarbij een belangrijke rol. Hieronder behandel ik achtereenvolgens de productvisie en de product backlog. 4.2.1 Productvisie Volgens Ken Schwaber, bedenker van Scrum, moet er een gezamenlijke productvisie zijn voordat een Scrumteam begint met de ontwikkeling van het systeem. Dit is essentieel om richting te geven aan het project en om continu gefocust te blijven op het leveren van meerwaarde voor de business. Bovendien kan een inspirerende visie zeer motiverend werken op het team. Zoals gezegd is de product owner verantwoordelijk voor het creëren en uitdragen van de visie. Hiermee geeft hij aan wat het eindproduct in essentie behelst en wat de toegevoegde waarde daarvan is. Een heldere visie geeft kort maar krachtig antwoord op de volgende vragen: Voor wie maken we het systeem? Wie zijn de klanten/gebruikers? Waarom willen zij het systeem kopen/gebruiken? Welke meerwaarde heeft het systeem voor hen? Wat zijn de Kritieke Succes Factoren? Welke eigenschappen moet het systeem zonder meer hebben? Hoe onderscheidt het systeem zich van de concurrenten/alternatieven? Wat zijn de Unique Selling Points? Is zo'n systeem technisch en financieel haalbaar? De visie geeft aan wat het doel van het project is en welke systeemeigenschappen daarbij cruciaal zijn. Het is niet eenvoudig om een goede visie te creëren. Het vereist een vooruitziende blik, inlevingsvermogen en verbeeldingskracht. Daarnaast is diepgaande kennis van de markt of de business waarvoor het systeem bedoeld is nodig. Hieronder volgen een aantal aandachtspunten voor het ontwikkelen van een visie. Kort en krachtig Een goede visie geeft in zo weinig mogelijk woorden de essentie van het eindproduct weer. De visie

7 moet voldoen aan de elevator test.. De visie bevat geen opsomming van de belangrijke systeemeigenschappen maar alleen de drie of vier cruciale eigenschappen. Dit laat ruimte voor het vinden van creatieve oplossingen. Feedback vragen Een visie is geen vaststaand gegeven. De behoeften van klanten/ gebruikers kunnen bijvoorbeeld wijzigen of verkeerd ingeschat zijn. Toets daarom de visie zo vroeg en zo vaak mogelijk en stel hem bij als dat nodig is. Nodig gebruikers uit op Sprint Review Meetings en vraag om feedback. Breng zo snel mogelijk een eerste release uit om te zien hoe de klanten/gebruikers erop reageren en vraag welke functionaliteit ze graag toegevoegd zien. Eerstvolgende release Een visie is bij voorkeur gericht op de eerstvolgende release van het systeem. Dit is een concreet doel en geeft een tijdshorizon die goed te overzien is. Bij agile-ontwikkeling wordt vaak eens per kwartaal een release uitgebracht. Gezamenlijke visie Het is van belang dat alle betrokkenen zoals Scrumteam, management, gebruikers en andere stakeholders hetzelfde beeld hebben van het eindproduct. Zonder gezamenlijke visie is er geen gezamenlijk doel en dat leidt vroeg of laat tot problemen en tegengestelde belangen. Een gezamenlijke visie versterkt het teamgevoel en bevordert de samenwerking. 4.2.2 Product backlog In de Scrum Guide is de product backlog omschreven als "een lijst met alle features, functies, technologie, verbeteringen en bug fixes die samen de veranderingen beschrijven die aan het product zullen worden gedaan in toekomstige releases". s". De items op de product backlog worden meestal (zie hoofdstuk 5). weergegeven als user stories (zie hoofdstuk 5).!"#$%&'($)$*+,-./0'$,-12345'*6$*789$'/'*6$* Een product backlog is niet hetzelfde als een traditionele lijst met SMART- requirements. De belangrijkste kenmerken van een goede product backlog heeft Mike Cohn in zijn boek Succeeding with Agile samengevat in het acroniem DEEP. De letters DEEP staan voor: Detailed appropriately De items in de product backlog moeten het juiste detailniveau hebben.

8 De user stories die in de komende sprint geïmplementeerd worden zijn klein en de user stories die voorlopig nog niet aan de beurt zijn zijn veel groter. Het is onverstandig om veel gedetailleerde user stories op de product backlog te zetten. ten. Dat is lastig te managen, is onoverzichtelijk, leidt tot veel rework en het inschatten en prioriteren van de kleine user stories kost veel tijd. Te veel details op de product backlog is verspilling van tijd en energie (waste). Estimated Voor ieder item op de product backlog moet de omvang ingeschat zijn. Het gaat om een relatieve schatting; niet om de tijd die nodig is om een user story te implementeren. Het team schat in hoe groot een user story is in vergelijking met een aantal referentie user stories. Bijvoorbeeld anderhalf keer zo groot of tien keer zo groot. Iedere user story krijgt een aantal punten. Aangezien deze punten relatief zijn en daardoor geen grootheid hebben, worden ze meestal aangeduid als story points. De schattingen zijn belangrijk omdat de product backlog onder andere dient als planningstool. In de product backlog is namelijk eenvoudig aan te geven welke user stories in een sprint en in een release meegenomen kunnen worden (zie hoofdstuk 1). Emergent De product backlog evalueert continu. De product backlog is dynamisch in de zin dat deze e voortdurend verandert om te kunnen weerspiegelen wat er nodig is om het product waardevol, concurrerend en beter te maken. De product backlog is daarom nooit af. De product owner en het team passen de user stories, de prioriteiten en de schattingen voortdurend aan de laatste inzichten aan. Die inzichten veranderen doordat je steeds meer te weten komt over het product, de gebruikers, de omgeving en de technologie en doordat de mening en behoeften van de stakeholders aan voortschrijdend inzicht onderhevig zijn.!"#$%&'($)$*+,-./0'$,-12345'*6$*789$'/'*6$* Prioritized De items op de product backlog moeten in volgorde van prioriteit staan. De user story met de hoogste prioriteit staat bovenaan en wordt als eerste geïmplementeerd. De product owner kent de prioriteiten toe, maar laat zich adviseren door stakeholders uit de business en door het team. Aspecten die meespelen bij het prioriteren van de user stories zijn: minimum marketable features, business value, risico's en afhankelijkheden. Prioritering ring is essentieel voor het leveren van zo veel mogelijk business value. De product owner is immers verantwoordelijk voor het maximeren van de Return on Investment (ROI).

9 5 User stories De items in de product backlog worden meestal weergegeven als user stories. Het is de aanbevolen requirementstechniek in een agile-omgeving. 5.1 Wat zijn user stories? User stories representeren requirements verteld vanuit het gezichtspunt van de gebruikers. User stories geven de business values en behoeften van de gebruikers weer en zijn in de terminologie van de business geformuleerd. User stories worden in korte eenvoudige zinnen beschreven bij voorkeur op de volgende manier: Als een <type gebruiker> wil ik <iets doen> zodat ik <er iets aan heb>. Ter illustratie enkele voorbeelden van user stories: Als boekkoper wil ik de klantbeoordelingen van een boek lezen, zodat ik beter kan beslissen of ik het boek wil kopen. Als een geregistreerde gebruiker wil ik een nieuw wachtwoord kunnen aanvragen, zodat ik weer toegang kan krijgen als ik mijn wachtwoord vergeten ben. Als marketingmanager wil ik de resultaten van oude advertentiecampagnes kunnen zien, zodat ik kan besluiten welke campagnes ik wil herhalen. advertentiecampagnes kunnen zien, zodat ik kan!"#$%&'($)$*+,-./0'$,-12345'*6$*789$'/'*6$* Als student wil ik mijn cijfers online bekijken, zodat ik sneller weet of ik het examen heb gehaald. Bovenstaande voorbeelden van user stories laten slechts de korte beschrijving zien waarmee de user stories worden aangeduid. Het zijn reminders voor de user stories. Het is uitdrukkelijk niet de bedoeling om de user stories (ofwel de requirements) volledig en tot in detail te beschrijven. Het is namelijk effectiever om de detailinformatie mondeling over te dragen. Het tweede en belangrijkste onderdeel van user stories is dan ook de mondelinge communicatie. Het gesprek

10 tussen het ontwikkelteam en de product owner over de gewenste werking van de user stories. Als een ontwikkelaar een user story gaat implementeren, heeft hij allerlei detailinformatie nodig. User stories dwingen hem om vragen te stellen aan de product owner. De product owner moet (bij voorkeur dagelijks) beschikbaar zijn voor het beantwoorden van deze vragen. Om de correcte werking van de gerealiseerde software vast te stellen worden indien nodig de antwoorden vastgelegd als acceptatiecriteria. De acceptatiecriteria vormen het derde onderdeel van user stories. Ook die acceptatiecriteria hoeven niet volledig te zijn. Het ontwikkelteam en de product owner werken immers intensief samen bij het implementeren van de user stories. Requirements detailleren, testen en software ontwikkelen gaan hand in hand. De ontwikkelaar laat regelmatig aan de product owner zien wat hij gebouwd heeft. De product owner geeft feedback en samen bespreken ze wat er nog toegevoegd of gewijzigd moet worden. Aangezien een user story in enkele dagen tot ruim een week tijd gerealiseerd wordt, is het niet nodig om naast de mondelinge afstemming nog veel te documenteren. User stories bestaan uit drie onderdelen: 1. een korte beschrijving als aanduiding van de requirement (i.v.m. planning); 2. mondelinge communicatie om de details te achterhalen (tijdens de realisatie); 3. acceptatiecriteria om juiste werking vast te stellen. 5.2 User stories of use cases User stories komen voort uit de agile-beweging en bestaan nog relatief kort. Use cases daarentegen zijn aan het eind van de vorige eeuw geïntroduceerd toen we nog alles uit de kast trokken om de requirements zo volledig en eenduidig mogelijk te specificeren. Het is daarom niet verwonderlijk dat in een agile-omgeving user stories duidelijke voordelen hebben boven use cases. De voordelen van user stories boven use cases zijn: User stories bevorderen de samenwerking!"#$%&'($)$*+,-./0'$,-12345'*6$*789$'/'*6$* User stories bevorderen de samenwerking In plaats van analisten een brugfunctie te laten vervullen tussen de business en de ICT, werkt het hele ontwikkelteam samen met de product owner om de user stories te detailleren. User stories stimuleren mondelinge communicatie Omdat beschrijvingen van user stories geen detailinformatie bevatten, ontkomt het ontwikkelteam bijna niet aan het stellen van vragen aan de product owner. Met user stories werken is eenvoudiger Het is niet nodig (en niet wenselijk) om vooraf de gedetailleerde requirements te achterhalen en te beschrijven. Dat is maar goed ook, want het is onmogelijk om de requirements (in use

11 cases of elders) voor 100% volledig en eenduidig te specificeren. User stories kosten minder tijd Mondelinge communicatie tussen het ontwikkelteam en de product owner kost minder tijd dan: o het specificeren van alle gedetailleerde requirements door een analist; o het lezen en begrijpen van die specificaties door de ontwikkelaars en testers; o het doorvoeren van wijzigingen in de specificaties. User stories kunnen beter omgaan met voortschrijdend inzicht De verschuiving van up front naar just in time requirements, zoals bij user stories het geval is, geeft maximale ruimte voor voortschrijdend inzicht. Tot aan de start van de iteratie/sprint waarin de user story geïmplementeerd wordt, heeft voortschrijdend inzicht geen negatief effect op het project. User stories hebben de juiste omvang In verband met het plannen van iteraties/sprints moeten user stories in maximaal tien werkdagen geïmplementeerd kunnen worden. Grotere user stories, meestal epics genoemd, kunnen eenvoudig opgesplitst worden. Use cases daarentegen omvatten hele scenario's inclusief de uitzonderingen die nodig zijn om een op zichzelf staand waardevol resultaat te leveren aan de gebruikers. Het is zelden mogelijk om een hele use case in tien dagen te implementeren. 5.2.1 Use cases 2.0 De bedenker van de use case, Ivar Jacobson, heeft eind 2011 zijn use case techniek uitgebreid en geschikt gemaakt voor agile-omgevingen. De hiervoor genoemde voordelen van user stories boven use cases gaan niet langer op voor use cases 2.0. In use cases 2.0 is aan de reguliere use case niets veranderd. Wel zijn er use case slices aan de techniek toegevoegd. Use case slices maken het mogelijk om een use case op te delen in kleinere, onafhankelijke werkeenheden (te vergelijken met user stories). Je kunt ze geleidelijk definiëren zonder dat eerst de hele use case uitgewerkt hoeft te zijn. Ook de verhouding tussen schriftelijke en mondelinge communicatie is naar eigen inzicht in te vullen. In het Requirements Kenniscentrum vind je meer informatie over user stories en use cases en een download link naar het gratis ebook van Ivar Jacobson.

12 Dit ebook is uitgegeven door Reaco Reaco leert requirementsanalisten in softwareontwikkelprojecten hoe ze de gebruikers aan betere systemen kunnen helpen. Dit doen wij door het geven van: Advies aan organisaties die hun requirementsproces willen professionaliseren. Coaching en training-on-the-job aan onervaren requirementsanalisten die snel het vak willen leren. Opleidingen en praktijkgerichte trainingen aan analisten die hun kennis en vaardigheden willen uitbreiden. De Reaco Academy biedt onder andere een agile-training specifiek gericht op business analisten, informatieanalisten en requirements engineers. Actuele informatie over deze 1-daagse training Requirements in Scrum vind je op onze website. Neem voor meer informatie over Reaco en het requirementsvak contact op via: Telefoon: 06-83579287 Email: Website: info@reaco.nl www.reaco.nl www.requirementskenniscentrum.nl Hartelijke groet, Nicole de Swart http://nl.linkedin.com/in/nicoledeswart