“Dat moet je echt niet willen!”

Iedere Product Owner met een mondig Scrum Team zal dit vroeger of later eens naar het hoofd krijgen. Je presenteert een nieuwe User Story op een Sprintplanning of tijdens een Backlog Refinement en nog voor je uitgesproken bent vallen de ontwikkelaars je in de rede: “Dit moet je echt niet willen!”
Daarna volgen, als het goed is, argumenten om de wil voor deze User Story uit jouw hoofd te doen verdwijnen.

Hoe voorkom je dat in je in lange functionele discussie’s beland zonder de wijsheid van je team compleet in de wind te slaan?

Begin met goed luisteren naar de tegenargumenten. Er kunnen een aantal zaken aan de hand zijn.

De kans bestaat dat je een verder uitgewerkte functie dan sec de User Story presenteert. Het commentaar van het team betreft het ontwerp van de functie en niet je User Story zelf. Je hebt bijvoorbeeld een vergeten-wachtwoord-functie bedacht met een email met het wachtwoord erin. “Niet veilig”, merkt een ontwikkelaar op. Goede feedback. Als je je als Product Owner bemoeit met het ontwerp van functionaliteit ga je voor een gedeelte op de stoel van het Team zitten. Luister dan ook heel goed naar hun feedback en stel je coöperatief op.

Het kan ook zijn dat de ontwikkelaars vinden dat je User Story weinig business waarde bevat, dat niemand er op zit te wachten, of dat je prioriteitstelling niet goed is.
Als het goed is heb je in het voorwerk het “zodat” gedeelte van je User Story ingevuld zodat je iedereen kunt uitleggen hoe de business met deze User Story gediend wordt, en welke stakeholders je met deze User Story bedient.

Let wel, het Team is geen stakeholder!
Doordat je veel face-time hebt met het Team, en ontwikkelaars vaak slimme mensen zijn met een mening, ontstaat de kans dat ze zich in verregaande mate met je backlog en prioriteiten gaan bemoeien. Dit is niet de bedoeling! Wijs ze daar zo nodig op als dit stelselmatig gebeurt. Ontwikkelaars zijn verre van representatief voor je gebruikers en kennen jouw business minder goed dan jij. Ze zijn er voor jou, om de User Stories te implementeren, niet andersom.

Het kan ook voorkomen dat men “Dit moet je niet willen!” roept omdat de User Story lastig te implementeren is. Ontwikkelaars geven dit niet altijd direct toe.
Bewust of onbewust komen de ontwikkelaars met allerlei argumenten waarom jij die User Story niet moet willen, zodat zij hem niet hoeven te bouwen.
Soms voert dit terug op dogmatisch aanhangen van bepaalde technologieën of frameworks en hardnekkig beeld over hoe de wereld en gebruikers zich daarbij moet gedragen. (Vraag bijvoorbeeld een JavaServerFaces-ontwikkelaar of hij de browser back-button werkend kan maken bij zijn applicatie). Soms ook valt de User Story te rauw op het dak van de ontwikkelaar en is het oplossingspad niet direct zichtbaar.

Probeer door dit type weerstand heen te breken. Het is prima acceptabel dat iets lastig te bouwen is, maar laat het Team dit verwoorden in een inschatting voor de betreffende User Story en niet door middel van allerlei technische discussie’s of gemorrel aan de vermeende business waarde.
Als er absurd hoge schattingen uit komen, en jij die User Story toch echt graag wilt, vraag ze dan wat langer na te denken. Vraag of het opgebroken kan worden in kleinere onderdelen of plan een Spike waarin binnen beperkte tijd meer kennis over het probleem opgebouwd kan worden met als doel de functie inschatbaar te krijgen.

Als voor je gevoel de belangrijke User Stories stelselmatig duur blijken qua implementatie, wordt de vraag legitiem of de gekozen architectuur wel goed past bij het probleemdomein.
Breng deze vraag te berde wanneer het team zelf verantwoordelijk is voor de architectuur. In veel gevallen is dat op een hoger niveau bepaald en is het team op basis van bepaalde kennis en ervaring van juist die technologie samengesteld. In dat geval kan het team niets met je vraag.

Concluderend: Luister naar het team voor feedback op het ontwerp, de Hoe van je User Story.  Voor wat betreft het Waarom van de User Story is het zaak deze zo goed mogelijk aan je team uit te leggen, maar de discussie alleen met je stakeholders te voeren.