Schrijf PBI's - en doe het goed

Het is niemands favoriete klus: Product Backlog Items (PBI’s) aanmaken om de komende Sprints op te kunnen pakken. En toch, het is een onderdeel van je werk als ontwikkelaar. En een belangrijk onderdeel ook, want zonder goed opgezette PBI’s kan een team helemaal niets.

(Goed, een team kan natuurlijk wel in het wilde weg gaan coderen, maar ik betwijfel of een opdrachtgever daar geld voor neer zou willen leggen. Nog los van de vermoeiende, chaotische situatie die het voor het team zelf creëert.)

Schrijf PBI’s

Er bestaan vast en zeker ontwikkelaars die menen dat het aanmaken van PBI’s niet hun taak (c.q. probleem) is. Volgens deze ontwikkelaars is het aanmaken van PBI’s de verantwoordelijkheid van bijvoorbeeld een business- of informatieanalist.

Helemaal onjuist is die veronderstelling niet, want het is ook de taak van een analist om PBI’s aan te maken. Maar daar volgt niet uit dat het niet ook de taak van de ontwikkelaar is om dat te doen.

De aard van jouw PBI’s

De aard van door ontwikkelaars geschreven PBI’s zal doorgaans verschillen van die van de analist. Een analist zal PBI’s schrijven waarin nieuwe features functioneel uitgewerkt worden. Een ontwikkelaar zal vaker technische PBI’s schrijven, bijvoorbeeld voor het wegwerken van technische schuld of het doorvoeren van een architecturele wijziging die nieuwe features mogelijk maakt.

Merk op dat een analist dit soort PBI’s waarschijnlijk niet eens aan kan maken, omdat ze buiten zijn expertise en/of blikveld vallen.

Het is aan de analist om de gewenste features helder te verwoorden, maar het is aan de ontwikkelaar om ervoor te zorgen dat de code op een dusdanig niveau is dat die features ook ondersteund kunnen worden. Soms moet daar extra werk voor worden verzet. En wat dat werk precies inhoudt zal toch iemand uit moeten werken.

Wie die iemand is? Drie keer raden.

Een kans

Daar kun je verbolgen over zijn, maar je kunt het ook zien als een kans. Jouw PBI’s geven je namelijk de kans om je applicatie te vormen op een manier waar jij als ontwikkelaar profijt van hebt. Wat zal er met de technische schuld van je applicatie gebeuren, denk je, als jij geen PBI’s schrijft om die weg te werken?

Een ontwikkelaar die het nalaat zulke PBI’s te schrijven, uit te werken en onder de aandacht van zijn Product Owner te brengen, bespaart zichzelf op korte termijn misschien wat moeite. Maar diegene maakt zijn eigen werk op lange termijn alleen maar moeilijker.

Doe het goed

De meeste ontwikkelaars vinden het helemaal niet leuk om PBI’s te schrijven. Ze houden zich liever met code bezig. Helemaal verwonderlijk is dat ook niet. Als ze niets liever deden dan features uitwerken, dan waren ze wel analist geworden.

Wat slechte PBI’s doen

Maar het wordt een probleem wanneer ze hun PBI’s daarom afraffelen. Ik denk dat veel ontwikkelaars heus wel weten dat het schrijven van PBI’s onder hun takenpakket valt, maar dat ze die verantwoordelijkheid liever niet hebben. Wat dan gebeurt, is dat ze hun individuele verantwoordelijkheid af proberen te wentelen op het team als geheel, tot nadeel van iedereen.

Zulke ontwikkelaars werken hun PBI’s minimaal uit en slingeren deze vervolgens de Refinement in. Dit zorgt voor een moeizaam en inefficiënt verloop van de meeting. Moeizaam, omdat het team veel tijd kwijt is aan elk PBI. Inefficiënt, omdat zes, zeven, acht man met z’n allen het werk van één persoon doen.

Denk je eens in hoeveel loonkosten je werkgever maakt wanneer je team dat ene PBI collectief uitwerkt dat je in je eentje in een halfuurtje voor had kunnen bereiden. Zou jij dat geld er zelf voor over hebben, als jij de baas zou zijn?

Zorg

Neem de tijd voor je PBI’s. Behandel ze met evenveel zorg als dat je je code behandelt. (Als je nu denkt: mooi!, dan zijn onuitgewerkte PBI’s waarschijnlijk de minste van je problemen.) Het is een investering die zich onmiddellijk terugbetaalt - voor je werkgever, maar vooral voor je team.

Goed uitgewerkte PBI’s brengen rust in de vorm van een concreet doel om naar te streven. Bij afwezigheid van zo’n doel verzandt een team in chaos.

Dat is een flinke prijs om te betalen voor oppakken van niemands favoriete klus.

product backlog items · professionaliteit · scrum · software ontwikkelaar (rol) · verantwoordelijkheid