De product backlog hoort geordend te zijn. Dingen die als eerste opgepakt moeten worden staan bovenaan, wat later mag komen staat onder.
In het algemeen wordt als advies gegeven dat de items op volgorde van waarde moeten staan. In mijn ervaring is dat echter te beperkt. Wat mij betreft bepaalt een mix van de volgende factoren de volgorde van de backlog:
- waarde – de waarde die de stories hebben voor de klant of gebruiker; meestal vraag ik de product owner om aan alle stories een getal toe te kennen (100 voor heel veel business value, 1 voor heel weinig);
- risico – spannende stories waar mogelijk ellende in zit moeten relatief hoog op de lijst staan; fail fast is beter dan fail late;
- technische afhankelijkheden – er is nu eenmaal vaak een bepaalde technische volgorde om dingen te bouwen.
In de keuze van backlog items voor de komende sprint komt er nog een aspect bij: het werkt veel prettiger als de items waaraan in een sprint gewerkt wordt aan elkaar gerelateerd zijn. Iets als: “In sprint 4 doen we rapportage, in sprint 5 implementeren we het zoeken”. Een sprint goal zorgt ervoor dat het team meer focus krijgt, meer gaat samenwerken tijdens de sprint en het leidt tot veel interessantere demo’s.
André Heijstek, Improvement focus