Agile Estimating & Planning

Een van de vele misverstanden over Agile Development is dat je ad hoc maar wat doet, want je moet immers wendbaar zijn. Geen plannen, geen documentatie, maar doen wat de klant roept want het gaat om toegevoegde waarde voor de klant. Ook in dit boek wordt met deze misverstanden korte metten gemaakt. De titel van het boek benadrukt dat ook het proces van schatten en plannen agile kan zijn.

In zes delen en 23 hoofdstukken behandelt de auteur alle aspecten van schatten en plannen. Hij legt het verschil uit tussen het schatten van de omvang van een hoeveelheid werk en de hoeveelheid benodigde tijd. De grootte van het werk wordt uitgedrukt in dimensieloze ‘storypoints’ of ideale dagen. Voor een specifieke iteratie worden de user stories opgebroken in taken en worden de taken geschat in uren werk. Middels een te schatten en te meten ‘velocity’, uitgedrukt in story points per iteratie, wordt het werk vervolgens vertaald in een doorlooptijd.

De schattingen die hij introduceert zijn geen puntschattingen, maar intervalschattingen. Het gaat immers niet om zekerheden maar om waarschijnlijkheden. Naarmate de tijd vordert en er meer informatie voorhanden is, kunnen schattingen worden bijgesteld. De vraag is nu: wat gaat het team maken voor de klant en in welke volgorde? Hier komt het onderwerp ‘waarde voor de klant’ aan de orde. Het derde deel van het boek, bestaande uit vier hoofdstukken, behandelt achtereenvolgens het priortiteren van thema’s (combinaties van user stories), financiele prioritering, het prioriteren op wenselijkheid (hier wordt een eenvoudige vragenlijst geintroduceerd) en het opsplitsen van user stories als deze te groot zijn om in een iteratie om te zetten in werkende en geteste code.

De delen vier en vijf gaan over het maken en onderhouden van een planning en over het communiceren van voortgang, zowel in termen van gerealiseerde functionaliteit (‘features’) als in termen van het project (wat is er inmiddels geleerd door het team, bijvoorbeeld voor wat betreft het schatten). Het laatste deel is een casus. Hier gebruikt de auteur de gevaarlijke vorm van ‘het verhaal’. Ik noem dit gevaarlijk omdat het vaak fout gaat: schrijvers van vakliteratuur zijn meestal geen begenadigde schrijvers van romans en dit leidt dan tot tenenkrommende lectuur (zie mijn referenties van ‘Physics of the future’ van Kaku en ‘Het doel’ Goldratt). Maar niet in dit geval. Het is een prima beschrijving die overtuigt. Overigens valt me op dat hij in alle voorbeelden vrouwen gebruikt. Schijnbaar komen er in zijn teams geen mannen voor. Allemaal erg politiek correct maar naar mijn idee ietwat overdreven. Gelukkig wordt dit gecorrigeerd in de casus, waarin een gemengd team wordt gevolgd.

Wat me aanspreekt is de hoge mate van concreet zijn van het boek. Je kunt er, met verstand, zo mee aan de slag. Alle aspecten van schatten en plannen komen aan de orde en bevatten allemaal een hoge mate van gezond verstand. Intuitief klopt het. Het leest gemakkelijk (iets meer dan 300 pagina’s; bij gemiddeld 20 pagina’s per uur dus ongeveer 15 uur lezen) en ik raad het geinteresseerden aan.

Geeft heel wat goede ideeën om je agile ontwikkeling te plannen.
Goed geschreven met vele illustraties.
Heel wat technieken voor planning uitgelegd met praktische voorbeelden

Motivation for reading:
While we do not practice “agile development” but rather (extremely) “lean agile”, I have the need to understand different angles on planning to improve our ability to predict shipping dates.

Readability:
This book is very accessible, with loads of examples and use-cases. It provides a good red line to follow, working from the lowest levels (estimating a story) to the highest levels (implementing for large distributed teams). I especially enjoyed the example at the very end, where you follow a team in their first agile workflow.

Lessons learned:
- Reasons for planning we previously did not consider enough, like “Reducing risk and uncertainty”.
- Mis-using storypoints in our planning tool (Pivotal tracker) due to the lack of understanding their meaning. Mistakes include re-estimation for the wrong reasons, treating story-points as a measure of “time”, not planning in iterations.
- Financial prioritirations, with different types of revenue/benefit (lower maintenance cost for example)
- How to prioritize desirability
- Iteration and release planning.

Conclusion:
I recommend this book for anyone who does any planning in the software industry, in teams of any size. You will walk away -at least- with a better understanding of why we’re getting it so wrong all the time.