In samenwerking met Sanne Müskens is op 15-05-2013 een artikel geplaatst op Dutch IT-channel:

Bij het inschatten en maken van planningen voor IT-projecten wordt vaak gebruik gemaakt van Planning Poker. Deze methode is erg populair bij bedrijven die de Agile-methode hanteren.

De populariteit komt voort uit het feit dat niet één persoon de planningen maakt, maar het gehele team dat de werkzaamheden ook daadwerkelijk uitvoert is betrokken bij dit proces wat leidt tot veel nauwkeurigere schattingen. Planning poker is een echt pokerspel, en bestaat uit meerdere sets kaarten met daarop de getallen 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 en 100. Deze symboliseren de relatieve grootte en complexiteit van een bepaalde opdracht. Het gebruik van Planning Poker binnen Agile trajecten kent veel voordelen, maar er zijn ook een aantal valkuilen.

In mijn rol als Testconsultant bij Bartosz ICT treed ik vaak op als ‘Scrum Master’ (begeleider tijdens het gehele proces) voor diverse opdrachtgevers. Ik wil graag mijn ervaringen met jullie delen en vijf veel voorkomende valkuilen bij Planning Poker toelichten.

1. Zorg dat je het spel begrijpt

Een valkuil is dat een Scrumteam Planning Poker gebruikt omdat men denkt dat het nu eenmaal bij de Agile manier van werken hoort. Ze gebruiken Planning Poker zonder dat ze voldoende kennis hebben van het principe. Fout! Aan Planning Poker zijn belangrijke consequenties verbonden. Er worden schattingen gedaan en aan de hand hiervan wordt de werkwijze bepaald. Ook is het van belang dat het hogere management begrijpt hoe Planning Poker werkt om misverstanden te voorkomen. In de praktijk gebeurt het weleens dat bijvoorbeeld het puntensysteem verkeerd geïnterpreteerd wordt, met name als er meerdere teams binnen een bedrijf Agile werken en gebruik maken van Planning Poker. Ikzelf heb weleens meegemaakt dat een manager binnen kwam lopen en zich afvroeg hoe het mogelijk was dat team 1 minder punten had dan team 2. Deze punten zeggen niets over de manier waarop er gewerkt wordt en hoe een team functioneert. De teams zelf weten dit wel, maar door het hogere management worden de punten soms in een verkeerde context geplaatst. Dit kan voorkomen worden door het management te betrekken bij Planning Poker en ze goed uit te leggen hoe het spel werkt en wat het doel is.

2. Doe geen aannames

Wanneer Planning Poker wordt toegepast dan kan een valkuil zijn dat eerdere uitkomsten en schattingen steeds opnieuw gebruikt worden en er niet telkens opnieuw gepokerd wordt. “Destijds zijn aan een bepaald item 20 punten toegekend, dit nieuwe item lijkt hier veel op dus laten we daar zonder opnieuw te pokeren ook 20 punten aan toekennen.” Dit is echt een valkuil! Het is goed om een ijkpunt te hebben, maar de situatie en omstandigheden veranderen en daarom is het belangrijk dat er steeds opnieuw gepokerd wordt. Er moet tijdens het pokeren niet teveel naar vorige sessies gekeken worden en er moeten geen aannames gedaan worden en conclusies getrokken worden op basis van vorige schattingen en uitkomsten. Zorg daarom dat de Product Owner aanwezig is om direct vragen te kunnen stellen bij twijfels.

3. Gebruik je pokerface

Bij Planning Poker is het de bedoeling dat men punten toekent aan een bepaald item en dat hier discussie over ontstaat om uiteindelijk tot een juiste schatting te komen. In de praktijk kan het voorkomen dat de teamleden elkaar, voordat de kaarten opgegooid zijn, teveel beïnvloeden. “Als Jantje 8 punten geeft, dan doe ik dat ook.” Een valkuil bij Planning Poker is dat men elkaar imiteert en daardoor niet op een objectieve manier punten toekent. Van belang is dat iedereen kritisch nadenkt, analyseert en punten toekent. Net als in het echter pokerspel, zet je ‘Pokerface’ op en laat de rest niet zien welke kaart je in jouw handen hebt! Wanneer iedereen elkaar nadoet en dezelfde kaart opgooit ontstaat er geen discussie, en daar is Planning Poker nou net voor bedoeld.

4. Een goede voorbereiding is het halve werk

Een veel voorkomende valkuil is dat User Stories (representaties van requirements vanuit gebruikersperspectief) niet helder genoeg zijn om te kunnen pokeren. Bijvoorbeeld wanneer blijkt tijdens de uitleg door de Product Owner en/of Business Analist dat er nog open eindjes zijn. Met lange discussies als gevolg en items kunnen dan niet (goed) ingeschat worden. Om dit te voorkomen is het raadzaam om concrete afspraken te maken over wanneer een User Story “ready for poker is”. Denk hierbij aan een verplichte reviewsessie of afstemming tussen Scrum Master, Product Owner en een belanghebbende vanuit de architectuur c.q. techniek. Ook is het belangrijk om goede acceptatiecriteria op te laten stellen bij een User Story, bij voorkeur met sprekende voorbeelden. Dit geeft namelijk houvast tijdens het pokeren omdat de juiste werking, en daarmee de oplossingsrichting, vastgesteld kan worden. Wanneer de juiste voorbereidingen gedaan zijn, verloopt Planning Poker soepeler en kunnen er betere schattingen worden gemaakt.

5. Denk multidisciplinair

De bedoeling van Planning Poker is dat het te realiseren werk multidisciplinair wordt bekeken. Dus niet alleen het eigen werk wordt ingeschat, maar elk teamlid maakt een schatting van hoeveel werk het voor het hele team is. Testen is hierbij in de praktijk vaak een ondergeschoven kindje. Er wordt dan te licht gedacht over àlle testaspecten. Dit is ook met Planning Poker soms het geval, waardoor de kans bestaat dat er te weinig tijd begroot wordt voor kwaliteitsborging. Met name in complexe omgevingen (met projectafhankelijkheden) moet goed bekeken worden of alle relevante testsoorten en –vormen voor het team meegenomen zijn in de schatting. Een tip in zo’n geval is om ook ketenpartijen te betrekken bij het pokeren. Door het multidisciplinair denken wordt Planning Poker nauwkeuriger gespeeld en wordt de valkuil van te eenzijdig schatten voorkomen.

http://dutchitchannel.nl/dic/25/237/vijf_valkuilen_bij_planning_poker.html