About Me

My photo
I improve the outcomes of IT development teams and people.

Friday, October 28, 2011

Een stoel als User Story

Binnen Scrum is een User Story het ankerpunt voor alles. De Product Owner stelt deze op en, als het Scrum team vindt dat het voldoet aan de Definition of Ready, dan kan het de Sprint Planning Meeting in.

Hoe maak je nu een willekeurige User Story tot een Ready User Story? Laten we daarvoor eens een analogie maken met een niet-ICT product: een stoel. Nu is een stoel een tastbaar product en geen User Story, dus dit is het eerste dat ook een echte Product Owner moet besteffen: hij/zij moet geen producten willen, maar oplossingen! En dan ook nog verwoord in een verhaalvorm. Laten we dat eens proberen...

  • <Als Product Owner wil ik kunnen zitten zodat ik niet moe wordt als ik eet.>

Dat is al duidelijk zat, nu alleen nog even de 'How to demo' en we kunnen aan de slag.


  • <Ik ga vijf minuten zitten en zal niet moe worden.>

Ook dat lijkt al duidelijk genoeg: hup, de Sprint Planning Meeting er mee in!

Zal dit goed gaan? Als oud-watervaller bekruipen mij de kriebels al. Toch kan dit goed gaan, maar de Kritische Succes Factoren worden nu wel mooi duidelijk:
  1. In de Sprint Planning Meeting, en in de Sprint, moet de Product Owner echt aanwezig zijn en vragen van de Scrum teamleden adequaat beantwoorden.
  2. De Scrum teamleden moeten goede vragen weten te stellen.

Vervolgvraag: Wat zijn goede vragen?

Dat zijn niet de vragen naar de functionals, maar naar de kwaliteitsattributen! Kai Gilb (zoon van Tom Gilb) noemt dat' Stakeholder Values and Product Qualities'.

Achterhalen van alle kwaliteitsattributen is iets wat voorheen een kwaliteitsmanager, requirements engineer en/of een testmanager deed. Die taken komen nu bij de Product Owner en in het Scrum team te liggen. En hier ligt een groot winstpunt te halen om een Scrum team echt naar 'Hyper Productiviteit' te brengen. Anders hebben we 4 sprints nodig om, via zitzakken, bierkratjes en tronen te komen tot een acceptabele eetkamerstoel: zelfde functionaliteit, andere 'Qualities'.

Monday, October 10, 2011

Hoe je de hele wedstrijd wint


In mijn vorige blog, van berg tot siergrind, heb ik al aangegeven dat niet alles Scrummend is op te lossen. Gelukkig wordt mijn mening bijgestaan uit onverwachte hoek: de rugby-spelregels!

Daarin staat dat het doel van dit spel is om ‘te proberen een ovale bal over de tryline van de tegenstander te drukken of tussen de palen te schoppen om zo punten te scoren’. Daarbinnen is een Scrum ‘een spelhervatting na kleine overtredingen of als de bal onspeelbaar is geworden, bijvoorbeeld wanneer een speler de bal laat vallen’.

Terug naar onze projectenpraktijk. Ook daarin zien we dat we niet alles met Scrum kunnen oplossen. Het spelletje heeft ook nog wat activiteiten voor en na de sprints!

Vaak zie ik dat na een aantal (ontwikkel-)sprints, er nog een ander traject gaat lopen. In dat traject worden dingen gedaan om de ‘Potential Shippable’ code verder af te testen en/of om zaken te regelen om het acceptabel te maken voor de beheerorganisatie. Om de bal over de lijn te brengen, zo gezegd.

Ook zie ik dat voorafgaand aan een Scrum-sprint nog het een en ander moet gebeuren voordat de Sprint Planning Meeting kan plaatsvinden. In het bijzonder is dat het afbreken van gecompliceerde Business wensen tot te verwerken User Stories, die voldoen aan opgestelde ‘Definition of Ready’.

En nu is de vraag: hoe doen we nu dat afbreken op een effectieve en efficiënte wijze? De Scrum Guide geeft aan dat dit proces ‘Product Backlog Grooming’ heet. En dat goed 'groomen' heel belangrijk is. Helaas geeft het weinig houvast over ‘hoe’ je dat moet doen. Het ligt redelijk voor de hand om voor dit probleem ook een ‘Lean’ manier te zoeken, en gelukkig is die er ook: Kanban.

Met de Kanban methode worden alle halffabricaten om te komen tot Ready User Stories, just-in-time gemaakt. Analisten, de Product Owner en het team gaan pas aan het Groomen van User Stories doen als er een echte klantvraag (pull) is. Zo wordt en geen onnodige voorraad opgebouwd en wordt de werklast in balans gehouden.

Voorwaarde is wel, dat de mensen in het Scrum team niet 100% op het Scrummen worden gealloceerd. Immers, met alleen maar Scrummen win je de wedstrijd niet: je zult ook moeten voorbereiden en afmaken!