Knowledge Hub

Over Scrum wordt vaak gezegd: het is makkelijk om te leren, maar moeilijk te beheersen. En dat klopt. Veel Team Coaches - de naam Scrum Master is aangepast sinds SAFe 6.0 - denken namelijk dat ze Scrum goed toepassen, maar eigenlijk werken ze vooral volgens het boekje. Een framework is inderdaad statisch, maar de praktijk is dat niet: daar moet rekening mee gehouden worden.

Als Product Owner heb je een zeer uitdagende rol. Er wordt vaak enige business kennis verwacht, maar je zult ook een behoorlijke technische bagage moeten hebben. Daarnaast is het cruciaal om een lean-agile mindset mee te brengen. Voor een Product Owner betekent dit vooral dat je instaat bent het team de ruimte te geven om de beste oplossing te zoeken en hierin niet vooringenomen over te zijn. Tot slot is stakeholder management een kerncompetentie voor ieder Product Owner. Helder en transparent communiceren om verwachtingen van zowel de klant als je agile te managen klinkt op papier een stuk makkelijk dan het in de praktijk vaak blijkt te zijn.

Een Product Owner zorgt voor de juiste inhoudelijke randvoorwaarden zodat het team goed kan leveren. Een Product Owner kan het team helpen door de klantvraag te verduidelijken, maar ook door zorg te dragen voor een snelle feedback cyclus van de klant. Daarnaast kan een Product Owner helpen door helder en duidelijk de volgorde or prioriteit van de backlog aan te geven. Dit zorgt ervoor dat het team zich kan richten op het bedenken van de juiste oplossing, in plaats van dat tijd verloren gaat aan het herdefiniëren van de vraag.

Tijdens PI Planning event maken de teams PI Objectives. Dit zijn de doelen die het team wil behalen gedurende de planningsperiode. Tijdens de sprintplanning stellen de teams ook doelen op per iteratie. Het resultaat in het halen van de iteratie doelen geeft de Product Owner inzicht in de haalbaarheid van de doelen die gesteld zijn voor Program Increment.

Tijdens de PI Planning is de rol van de Product Owner erg belangrijk. De teams wordt een backlog aangereikt met daarop Features. Tijdens de PI Planning moeten daar Stories van gemaakt worden die door de teams worden gepland. De Product Owner werkt met het team samen om de Features goed uit te werken naar Stories, zodat het team de inschatting kan maken van de benodigde inspanning. Daarmee wordt de planning voor de verschillende iteraties gemaakt op basis van de beschikbare capaciteit per team.

In SAFe is een Product Owner verantwoordelijk voor de team backlog en is een Product Manager verantwoordelijk voor de ART backlog. Daarmee is een Product Owner verantwoordelijk voor Stories en een Product Manager voor Features. Dat is een belangrijke afwijking van hoe dit bijvoorbeeld in scrum is vormgegeven. In SAFe gaan we ervan uit dat er meerdere teams nodig zijn om een verbetering, verandering of vernieuwing in een product te realiseren. Dat betekent dat we het werk tussen deze teams ook goed moeten afstemmen. De Product Manager zorgt er dus voor dat de complexere klantvragen uitgewerkt worden samen met de relevant Product Owners. De Product Manager heeft een specialistische rol, maar staat in hiërarchie in principe niet boven de Product Owner.

Een story is het kleinste type veranderopgave dat we kennen in SAFe. Het is werk dat moet kunnen passen in een iteratie voor één team. Hier werken de Product Owner en het agile team samen om tot een goed afbakening van de scope te komen.

Een Feature is een veranderopgave die voor een Agile Release Train genoeg werk geeft voor een volledige Program Increment, de planningperiode van tussen de 8 en 12 weken. Een verzoek voor een Feature komt vaak vanuit een Epic, maar het kan ook een op zichzelf staande vraag zijn. In een Feature worden de benefit hypothese opgeschreven en de acceptatiecriteria die beschrijven wat er af moet zijn om een werkende oplossing voor de klant van het product te maken.

Een Epic is een veranderopgave van significante omvang. Het is de grootste orde grootte werk die we kennen in SAFe en is doorgaans groot genoeg om voor een heel team meer dan één Program Increment aan werk te geven. Vanwege het karakter van een epic vindt de besluitvorming vaak plaats op een centraal niveau in de organisatie. Om goede besluitvorming te kunnen ondersteunen werken voor dit soort grote ideëén dan ook een epic value statement en een lean business case uit. Vervolgens wordt een minimum value product bepaald de haalbaarheid van de epic te toetsen. Dit wordt gevat in een (aantal) features voor de betreffende Agile Release Trains.

De Product Owner maakt zijn team backlog door samen te werken met de Product Manager van de agile release train en met de stakeholders van het team. Hierin geeft de product owner richting in de vraag die naar het team gaat. Samen met het team worden vervolgens de user stories uitgewerkt en worden er acceptatiecriteria toegevoegd, zodat het team weet de oplossing aan moet voldoen.

De Product Owner maakt zijn team backlog door samen te werken met de Product Manager van de agile release train en met de stakeholders van het team. Hierin geeft de product owner richting in de vraag die naar het team gaat. Samen met het team worden vervolgens de user stories uitgewerkt en worden er acceptatiecriteria toegevoegd, zodat het team weet de oplossing aan moet voldoen.

Een Team Backlog bevat het werk voor een team in een agile release train. Hier staan user-stories op die de Product Owner met het team heeft uitgewerkt en die klaar zijn om in de komende sprints opgepakt te worden.