samen
werken
5 tips voor een goede sprint planning
Een goede voorbereiding is het halve werk, zeggen ze weleens. Nu geldt dat absoluut ook voor een Sprint Planning. Factoren waar we mee te maken hebben bij deze vergadering, zijn onder andere: Stakeholdermanagement , Product Backlog management, Prioriteren en Zelforganisatie. Deze punten spelen een cruciale rol in de effectiviteit ervan. Vraag je je wel eens af hoe je jouw Sprint planning kan verbeteren? In dit blog geven we je 5 praktische tips om een goede Sprint Planning te bewerkstelligen.
Het probleem in de praktijk
In de praktijk zijn er vaak terugkomende gedragingen te zien die nauwer verband houden met de oude manier van werken dan met de nieuwe manier van zelforganiserend werken. Dat is zonde, want vaak zijn het juist deze elementen die belangrijk zijn voor de verandering. Onthoud dat mensen het liefst vasthouden wat ze het meest vertrouwd is en dat heeft vaak te maken met bijvoorbeeld controle, elkaars rol invullen, of micro-management. Daar wil je juist vanaf!
Dit uit zich in allerlei (disfunctionele) gedragingen. Denk hierbij bijvoorbeeld aan een Sprint Planning waar gesprekken tot niets leiden omdat er van alles door elkaar besproken wordt. Ook zijn er situaties waarbij probleem en oplossing in één worden gedeeld of inzichten niet de aandacht krijgen maar snel naar de mening van de volgende persoon wordt overgestapt. Ook wordt dikwijls bij het plannen vergeten om zowel in- als uit te zoomen waardoor te snel diepgang op een onderwerp ontstaat welke achteraf niet het meest belangrijk blijkt te zijn.
5 handige tips om jouw Sprint planning te verbeteren
Tijd dus voor verbetering. Daarvoor zijn er een vijftal handige praktische tips voor een goede Sprint Planning die we graag delen:
1. Refinement en Sprint planning splitsen in aparte time-boxes
Geregeld zien wij dat de refinement en de Sprint planning door elkaar heen lopen, of dat er zelfs geen eens een refinement is. Refinement definiëren we in dit geval als de aanscherping en het detail geven aan de Product Backlog items. Met andere woorden, dit is een perfect moment om de developers en de Product Owner inhoudelijk in contact te laten treden met elkaar. Dit is een zogeheten divergeer-situatie, dus diepgang op de items is belangrijker dan al te snel besluiten nemen. Het goed begrijpen van de user story en eventueel aanscherpen ervan is essentieel.
In de Sprint planning zelf blijft dan de ideale situatie over om slechts de geprioriteerde Product Backlog items te selecteren en daarmee het Sprintdoel bepalen. Door een harde knip te maken tussen deze 2 vergaderingen voorkom je dat er veel informatie verloren gaat. Gebruik de Timeboxes van de Refinement en daarna de Sprint Planning als criteria van de harde knip/afkadering.
Kortgezegd, maak van de refinement en Sprint Planning 2 apart getimeboxde meetings, dan blijven 1. bespreken en 2. beslissen goed gescheiden.
2. Prioriteren vooraf
Prioriteren in Scrum gebeurt idealiter op basis van klantwaarde. Prioriteren zorgt voor het scheppen van duidelijkheid en kaders, zodat operationele teamleden (Developers) weten wat zij mogen oppakken. Het bevorderen van een constructieve Sprint Planning, waar de nadruk ligt op bepalen welke items worden opgepakt, geschied dus het beste als de Product Owner deze prioritering voorafgaand al heeft gedaan. Idealiter is hier afstemming met de meest belangrijke gebruikersgroep voor het thema van komende sprint. Daarnaast is ook duidelijk op welke eenduidige criteria de prioriteiten gesteld zijn.
3. Inschatten en zelforganisatie
Een effectieve Sprint Planning kenmerkt zich door een opsplitsing tussen het ‘wat’ en het ‘hoe’. Dat betekent dat de Product Owner idealiter toelichting geeft op de prioriteiten van de Product Backlog, met daarbij de bijbehorende context vanuit de stakeholders op de verschillende items. Op deze manier begrijpen de Developers wat er toe doet en kunnen de developers vervolgens als team het Sprintdoel bepalen. Dat gebeurt door het selecteren van alle items die binnen de Sprint opgeleverd kunnen worden. Dit is dus in eerste instantie een teamcommitment.
In de praktijk zie je weleens dat hier al op individueel niveau items van de Product Backlog geselecteerd worden, echter schuilt hier een groot gevaar. Namelijk dat er geen volledige teamverantwoordelijkheid voor het Sprintdoel wordt gevoeld. Idealiter selecteert het development team dus eerst tezamen alle items, verplaatsen ze deze items naar de Sprint Backlog en vanuit daar kunnen items aan personen gehangen worden. Vervolgens is het aan de developers onderling om goede dialogen te houden over de oplossingen of uitvoering (het ‘hoe’) van de items. Hoe beter onderling overleg en begrip, hoe meer kans op de meest waardevolle oplevering.
4. Het Sprintdoel
Over het bepalen van het Sprintdoel zijn nogal eens wat onduidelijkheden. Bepaal je nu van te voren een thema of kijk je juist naar losse waardevolle onderdelen (de User Stories) en volgt uit de optelsom hiervan het Sprintdoel? Het belangrijkst van een Sprintdoel is dat het een gedragen commitment is door het gehele team op elk afzonderlijke item. Dit gebeurt vrij weinig in de praktijk, terwijl dit praktisch met een mooie processtap heel goed te voorkomen is.
In de praktijk zie je wel eens dat individuele teamleden bij het zien van de Product Backlog items, op individueel niveau items pakken. Dat betekent dat de letterlijke flow van het item van Product Backlog naar Sprint Backlog door één persoon gedragen wordt. Dit resulteert dan ook vaak in silo’s want niemand zal zich later tijdens de Sprint verantwoordelijk voor het item voelen.
Om dit te voorkomen is er een hele simpele tip: laat éérst alle items als totaal team gecommitteerd worden en dan pas individueel toebedelen. Hoe? Door de items te verschuiven naar de Sprint Backlog voorraad, de vraag te stellen: ‘kunnen jullie je hier als team op committeren?’ en dan pas vanaf de Sprint Backlog de items per individu verdelen.
5. Voer het juiste gesprek (in en uitzoomen)
Je kan alle structuren en werkwijzes nog zo goed hebben bedacht, de uitvoering en daarbij het gedrag en de cultuur zijn essentieel voor succes. Daarom wil je het juiste gesprek voeren. We doen namelijk allemaal aan communicatie, echter is deze niet altijd effectief. Zo kunnen de gesprekken soms te beschouwend, te destructief en te abstract blijven.
Wat hierbij helpt is een onderscheid te maken tussen alle inzichten en opties die er zijn en daarna pas de juiste onderdelen inhoudelijk te bespreken. Dit volgt uit het uitzoomen/inzoomen principe wat essentieel is bij innovatie om de emergente informatie te benutten. Zie het als een taart. Waarschijnlijk beoordeel jij die slagroomtaart ook eerst in zijn geheel: je bekijkt welke fruitstukjes erop liggen, hoe de stukken verdeeld zijn (groot/klein) en waar de meeste slagroom zit. Vervolgens kies jij dat puntje wat jou het meest aan spreekt (en dus waarde heeft). Zo doen we dat ook met Product Backlog items!
Tot slot
Het leuke van deze tips is dat ze heel eenvoudig toe te passen zijn in jouw volgede Sprint Planning. Pak er stap voor stap 1 bij en probeer hem gewoon uit. Reflecteer hierop tijdens de Retrospective, zodat je ook echt vanuit daar de team learnings kan meenemen. Wellicht kom je dan tot nieuwe ontdekkingen. En laat die ons vooral weten!
Heb jij dit artikel gelezen maar heb je toch nog vragen? Aarzel niet en neem contact op via 020 2614 195 of info@agilescrumgroup.nl, één van onze consultants helpt je graag verder.
Ook interessant:
- Stakeholders feedback vragen? Dit zijn 6 manieren
- Stakeholders betrekken, hoe doe je dat?
- 7 Waardevolle Product Owner Skills
