Tips voor een goede samenwerking tussen analist en product owner

Tips voor een goede samenwerking tussen analist en product owner

Ronald Koenis & Marco Balvers

Als analist werk je in projecten samen met collega’s die verschillende taken en verantwoordelijkheden hebben. Een goede onderlinge samenwerking en communicatie is dan cruciaal om op een efficiënte manier tot een waardevolle (software)oplossing te komen.

Dit artikel is de derde van een reeks publicaties waarin we als analisten praktische tips delen om efficiënt met verschillende andere rollen in een project samen te werken. Dit keer staat de samenwerking tussen analist en product owner centraal.

De analist verzamelt WAT de wensen van de business zijn, structureert deze en legt ze begrijpelijk vast. De product owner bepaalt WAAROM het team NU zo’n businesswens moet realiseren. Deze samenwerking zorgt voor een (software)oplossing die de meeste waarde oplevert voor de business.

In dit artikel delen we praktische tips waarmee analisten de samenwerking met de product owner voor, tijdens en aan het eind van een sprint uit Scrum kunnen optimaliseren.

Tips voor de voorbereiding van de sprint

In Scrum heeft de product owner een zware rol in het samenstellen van de product backlog. Hij bepaalt de stories en in welke volgorde het team ze zal realiseren. Dat vereist een brede kennis van business en IT en de kunde om een story helder te formuleren. Er zijn natuurlijk product owners die dat allemaal in zich hebben, maar in de praktijk zien we dat de analist hem vaak helpt bij deze taken.

De analist is binnen Scrum als lid van het ontwikkelteam verantwoordelijk voor het ontwerp en de documentatie van het systeem. Als Scrum wordt opgeschaald – of dat nu SAFe, Nexus of LeSS is – dan zien we dat analisten ook worden ingezet om het grote geheel te bepalen en te bewaken.

In de agile praktijk komen analistenteams ook los van de ontwikkelteams voor. Een dergelijke splitsing kan gezien worden als een Scrum anti-patroon dat een groot risico op te veel en te vroeg uitwerken en kennisverlies bij de overdracht geeft. Bovendien leidt het in veel gevallen tot een minder flexibel voortbrengingsproces.

Praktische tips voor de analist

Wil je als analist de sprint optimaal (efficiënt, en zonder waste) voorbereiden? Dan kunnen deze tips je zeker helpen:

  • Voorzie in en bewaak het “grote plaatje”. Een product owner krijgt van alle kanten informatie en wil die in een groter geheel kunnen plaatsen. De analist is de uitgelezen persoon om hem daarbij te helpen. Hij kan de product owner immers helpen om te bepalen welk deel nu het meeste waarde oplevert. DiVetro heeft daar trouwens handige hulpmiddelen
  • Als analist ben je de vertaler van de businesstaal van de product owner en de IT-taal van het team. Neem die rol serieus en ontwikkel begrip om spraakverwarring tussen beide werelden te voorkomen. Hanteer bijvoorbeeld een begrippenlijst of glossary.
  • Als een product owner overbelast is dan is het verleidelijk voor de analist om op te treden als product owner by proxy. In dat geval doet de product owner het werk richting stakeholders. De analist richt zich dan op het team en bepaalt bijvoorbeeld de prioriteit. Dit ontlast de product owner mogelijk wel maar het geeft een groot risico dat de analist niet de beste volgorde kiest. Het is dan ook beter om de product owner in zijn rol te laten en hem op basis van werkafspraken bij te staan in het uitwerken van stories. Dat kan bijvoorbeeld door het verfijnen van de acceptatiecriteria, het toetsen van externe vereisten of het leveren van input voor planningstools, zoals WSJF.
  • Als je als analist naast stories bijvoorbeeld ook features, epics of thema’s moet uitwerken voor de product owner, zorg dan altijd voor samenhang en behoud van het grotere geheel. Losse stories kunnen ondersneeuwen op de back log of leiden tot een grote lijst aan stories waar de product owner niet meer doorheen komt. Breng altijd een tracering aan naar de epic/feature en splits alleen als het echt nodig is op het moment dat het echt nodig is.
  • Houd rekening met de behoefte van zowel de product owner als het ontwikkelteam. Waar de product owner vaak naar de grote lijnen kijkt heeft het team meer behoefte aan details. Dit kan je oplossen door de details los of in bijlagen te bewaren, zodat de story zelf kort kan blijven. Goede templates en richtlijnen helpen hierbij het resultaat consistent te houden.

Tips voor tijdens de sprint

Als een story in de sprint komt dan is het de verantwoordelijkheid van de analist om de story (net) helder genoeg te krijgen en om de story te laten bouwen en testen. In de uitwerking komen soms nieuwe keuzes naar boven, die de analist met de product owner afstemt.

In Scrum is er ruimte om ook tijdens de sprint met de product owner over de scope te onderhandelen. Hiermee kunnen de analist en product owner voorkomen dat situaties die niet voorkomen in de praktijk, in scope blijven en tot waste leiden.

Praktische tips voor de analist

  • Voorkom dat de product owner analyse-klussen op de product backlog plaatst. Analyse-stories leveren geen business value op, maar wel waste, aangezien je vast meer uit-analyseert dan het team die sprint nodig heeft. Streef ernaar om het analyse-werk als taak van de realisatie van een story uit te voeren. Zo loopt het ontwerp niet voor. Bovendien kan je zo veel makkelijker inspelen op voortschrijdend inzicht tijdens de sprint.
  • Laat je ontwerp reviewen door de product owner, of beter nog: neem ontwerpbeslissingen met hem door. Hoe eerder ontwerpfouten of misverstanden aan het licht komen, hoe beter. Het mag niet zo zijn dat de product owner je ontwerp niet begrijpt. In dat geval moet je iets doen aan de kennis van de product owner of aan je eigen kunde.

Tips aan het einde van de sprint

In de sprint review zal de analist de business context van een oplevering geven. Een product owner kan die aanvullen vanuit zijn achtergrond.

Praktische tips voor de analist

  • Zorg dat stories vóór de review zijn goedgekeurd door de product owner. Spreek zowel met hem als met de tester af welke tests moeten zijn gedaan en controleer de uitvoering. Daarmee voorkom je ongewenst gedrag van de oplevering tijdens de sprint review. Bij de sprint review kan de product owner zich concentreren op aanvullende wensen of op nieuwe inzichten die stakeholders aanleveren. Dat is zijn rol. De analist moet duidelijk maken hoe de oplevering werkt, zodat de stakeholders kunnen aangeven of dat volgens hen goed genoeg is.
  • Als teamlid zal je meediscussiëren over toekomstige stories. Als er nieuwe wensen bij een sprint review naar boven komen dan is het de taak van de analist om die in het grotere geheel te plaatsen. Zo krijgen de product owner en stakeholders een beter inzicht in de plek en prioriteit van nieuwe stories.

Conclusie

Binnen een Scrum team is de analist vaak een eerste aanspreekpunt voor de product owner. De product owner gaat over het WAAROM en geeft de context, zodat de analist kan bepalen WAT daarvoor nodig is. In deze samenwerking kan het team de software ontwikkelen die het meeste businesswaarde oplevert.

Meer informatie

DiVetro heeft veel ervaring met de interactie tussen analist en product owner in Scrum. Wij vertellen je graag hoe je deze samenwerking kunt structureren en verbeteren.

Ronald Koenis is een senior analist die zelf ook de rol van product owner voor verschillende diensten van het Kadaster heeft ingevuld. Als analist maakt hij ontwerpen voor bedrijfskritische systemen, niet alleen bij het Kadaster, maar ook in heel andere branches zoals bij grootgrutter Albert Heijn en de verzekeraar Euler Hermes. Hij is in staat complexe IT-oplossingen zo weer te geven dat die voor de business te begrijpen zijn en tegelijkertijd voldoende specifiek zijn, zodat IT ermee aan de slag kan.

Marco Balvers is senior informatieanalist bij DiVetro. Hij heeft meer dan 15 jaar IT-ervaring. Marco helpt organisaties met Agile werken en het inpassen van Use Case 2.0 in hun bestaande werkwijze. Momenteel werkt Marco als analist binnen een Scrum team van de NS. Dit team is verantwoordelijk voor de ontwikkeling van apps voor eerstelijns medewerkers. Lees hier meer over de NS-case.

Geen reactie's

Geef een reactie