Agile project management - schatten en meten

Voor de eerste sprint hebben de ontwikkelaars en software architect in het project een inschatting van de zwaarte van User Stories gemaakt met behulp van Planning Poker kaarten, daarbij gefaciliteerd door de Scrum master.

Bij het meten van de uitvoering, in het onderhanden project met de GreenHopper plugin op Atlassian's JIRA, speelt onder meer de burndown chart een belangrijke rol.

Maar wat als de zwaarte van een te realiseren stuk software niet overeenkomt met de (gepercipieerde) zwaarte vanuit optiek van een tester, of - zij het eerder aangegeven - ontwerper? Kun je wel veilig Story Points per dag als maatstaf voor de productiviteit van een team spreken, als rollen van ontwerper, ontwikkelaar en tester niet uitwisselbaar zijn?

De bedachte work-around is een schatting te vragen van de afzonderlijke rolhouders, dus een schatting van de ontwikkelaars, ontwerpers en testers. Waar de zwaarte sterk uiteenloopt (makkelijk om te ontwerpen, redelijk bouwbaar, maar verrekte lastig om te testen) moet ouderwets gepland, gepuzzeld en geschoven worden met
- de beschikbare capaciteit in de verschillende rollen
- de volgorde van oplevering van User Stories

Was deze uitdaging ook opgetreden bij hanteren van een andere eenheid van werk, zoals het bij het Capgemini Accelerated Delivery Platform gebruikte Smart Use Case? Ik vermoed van wel, gegeven de leegte bij de disciplines Development (wat is het verschil met Code and deliverable generation?), Testing en Acceptation.

Apart vooraf schatten OK, maar commitment van het team voor de inhoud van de sprint, en dus ook het meten van de productiviteit van het team tijdens de looptijd van de sprint, blijft onverkort staan. Als projectleider heb ik immers niets aan achteraf wijzen naar elkaar (ja, maar zij zorgden voor vertraging!).

Heb je ervaring met deze planningperikelen? Deel dan je ervaring met een commentaar.