Van up front naar just in time requirements
We zijn gewend om requirements te definiëren ver voordat de ontwikkelaars ze gaan implementeren (up front). We weten inmiddels ook dat wijzigingen in de requirements onvermijdelijk zijn. Agile projecten stellen daarom het vaststellen van requirements zo lang mogelijk uit. Zij hebben de omslag gemaakt van up front naar just in time requirements.
Hoe juiste requirements identificeren
De juiste requirements identificeren is niet alleen belangrijk om een systeem te kunnen bouwen dat voldoet aan de behoeften van de gebruikers. Het bespaart ook heel veel werk. Uit onderzoek blijkt namelijk dat 80% van de toegevoegde waarde wordt geleverd door 20% van de functionaliteit van het systeem. Maar hoe identificeer je de juiste requirements?
Just enough requirements
Dat is makkelijk gezegd 'precies genoeg requirements', maar wat bedoelen we daar eigenlijk mee? Agilisten praten over Just enough requirements om aan te geven dat er niet te veel requirements mogen worden uitgewerkt. Terwijl men bij het meer traditioneel Requirements Engineering (waterval) juist streeft naar volledigheid van de requirements.
Scrum geschikt voor...?
Agile en Scrum zijn binnen de software ontwikkeling ongekend populair. De voordelen van een agile werkwijze zijn dan ook indrukwekkend. Veel organisaties zijn inmiddels geheel of gedeeltelijk overgestapt op Scrum of hebben pilot projecten lopen. Van andere organisaties krijg ik regelmatig de vraag 'Voor welke type projecten is Scrum nu eigenlijk wel en niet geschikt?'.
Sprint ready (deel 3)
Het derde deel in de serie over het sprint ready maken van user stories gaat over het minimaliseren van de features. Dit is een belangrijke stap in de gepresenteerde aanpak. De wijze waarop het systeem de functionaliteit biedt kan namelijk variëren van heel eenvoudig en basic tot bijzonder luxe. Agile teams breiden basale functionaliteit geleidelijk uit, te vergelijken met een schilderij dat steeds meer vorm krijgt. In deze blogpost vind je de bijbehorende patterns en voorbeelden.
Sprint ready (deel 2)
In Sprint ready deel 1 heb ik een aanpak voor het sprint ready maken van user stories geïntroduceerd. Nu ga ik dieper in op de eerste stap waarin uitsluitend de activiteiten die cruciaal zijn voor de gebruiker worden geselecteerd. Het absolute minimum dat nodig is om business value te leveren. Dit zijn zelden meer dan twee of drie activiteiten. Lees de uitleg aan de hand van voorbeelden en patterns voor het opsplitsen van user stories.
Sprint ready (deel 1)
Een user story is sprint ready als het ontwikkelteam de story in enkele dagen kan implementeren. Ook deze stories moeten op zichzelf business value leveren. Dit bereik je door grotere user stories op de juiste manier op te splitsen. Veel agile teams blijken daarbij moeite te hebben met het business value-criterium. Gebruik daarom deze drie stappen voor het sprint ready maken van user stories.
Product owner
Scrum onderkent slechts drie rollen (het ontwikkelteam, de product owner en de scrummaster) met alle drie een duidelijke focus en verantwoordelijkheid. De product owner is verantwoordelijk voor het succes van het product (IT-systeem) en het maximaliseren van de return on investment (ROI). De product owner is een uitdagende rol die om een full-time inzet vraagt.
Scrum en requirements
Scrum kent geen requirementsfase en onderkent ook geen analistenrol. Dit betekent niet dat requirements onbelangrijk zijn binnen Scrum. Integendeel, Scrum heeft expliciet aandacht voor het voortdurend verfijnen en bijstellen van de requirements. Waar en wanneer spelen requirements een rol binnen Scrum?
Product backlog: DEEP
Vrijwel ieder agile project maakt gebruik van een product backlog. De belangrijkste kenmerken van een goede product backlog zijn samengevat in het acroniem DEEP. Dit in tegenstelling tot een traditionele lijst met SMART requirements. Is je product backlog DEEP of SMART?
Agile: incrementeel en iteratief
Als het gaat om de werkwijze binnen ICT-projecten worden incrementeel en iteratief vaak in één adem genoemd. Ook een agile-aanpak combineert incrementeel en iteratief werken. Wat is eigenlijk het verschil tussen incrementeel en iteratief? Kan een ICT-project alleen incrementeel en niet iteratief werken en omgekeerd? Waarom is een agile-aanpak incrementeel en tevens iteratief?
Visie op eindproduct
Bij de start van een Scrum-project moeten minimaal de producten Visie en Product Backlog aanwezig zijn voordat het scrumteam begint met de ontwikkeling van het systeem (Ken Schwaber). Toch ontbreekt een gezamenlijke visie op het eindproduct nogal eens in scrum-projecten. Lees hier welke onderwerpen en aandachtspunten van belang zijn voor de visie.
User stories
Heb je weleens overwogen om user stories te gebruiken bij het achterhalen van de requirements? Het is de aanbevolen requirementstechniek in een agile omgeving. Aangezien steeds meer organisaties overstappen op agile softwareontwikkeling winnen user stories aan populariteit. Dit moet je weten als je besluit om met user stories te starten.
