SMART + INVEST = Requirements + User Stories
Kwaliteitsdenken
(leestijd 2 min.)
‘The difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships’.
Deze quote van Linus Torvalds op Github raakt de kern van kwaliteitsdenken en de wijze waarop requirements bepaald worden. Met de introductie van de Agile benadering in combinatie met de Scrum methodiek is in plaats van slechts het benoemen van requirements, meer nadruk komen te liggen op de wijze waarop requirements tot stand komen.
Requirements kun je zien als de eisen waaraan een product of dienst moet voldoen.
User stories omvat een korte beschrijving (Story) van wat een gebruiker (User) wil.
Zeker niet alle requirements zijn geschikt voor User Stories, een opinie welke ook gedeeld wordt door Ian Mitchel van Scrum.org . Kort samengevat komt het erop neer dat:
• ‘Business Requirements’ geschikt voor User Stories
• ‘NFR’s’ (Non Functional Requirements) geschikt voor User Stories, tenzij zeer expliciet
• ‘Technical Requirements’ nauwelijks geschikt voor User Stories
• ‘Defects’ ongeschikt voor User Stories
SMART versus INVEST
Om het verschil tussen een Requirement en een User Story te verduidelijken wordt veel gebruik gemaakt van twee acroniemen:
• Requirement = SMART : Specifiek, Meetbaar, Acceptabel, Realistisch, Tijdgebonden
• User Story = INVEST : Independent, Negotiable, Valuable, Estimable, Small, Testable
Het onderscheid zit in het wat meer dwingende karakter van requirements en de vrijere interpretatie van User Stories. Maar beiden wel bedoelt voor het realiseren van een product of service dat aan de eisen c.q. wensen van de gebruiker voldoet.
Afbeelding 1: animatie verschil tussen User Story en Requirement
Voor een goed begrip waaraan User Stories minimaal aan voldoen, heeft Bill Wake’s het volgende manifest opgesteld.
Figuur 1: INVEST uitgangspunten User Stories
| Independent | Stories should be as independent as possible from other stories, to allow them to be moved around with minimal impact and potentially to be implemented independently. If stories are tightly dependent, consider combining them into a single user story. |
| Negotiable | Stories are not a contract. They are “placeholders” for features which the team will discuss and clarify near to the time of development. |
| Valuable | Stories should represent features providing clear business value to the user/owner of the solution and should be written in appropriate language. They should be features, not tasks. |
| Estimable | Stories need to be clear enough to estimate (for the appropriate timeframe), without being too detailed |
| Small | Stories should be small enough to be estimated. Larger “Epic” stories should be broken down into smaller User Stories as the project progresses. The stories after splitting still follow the INVEST criteria. |
| Testable | Stories need to be worded clearly and specifically enough to be testable. |
(Bron: www.agilebusiness.org)
Voordat een User Story naar Development gaat is gebruik gemaakt van de 3 C’s:
Card (het verhaal), Conversation (overleg) en Confirmation (bevestiging).
Integraal
Een niet limitatieve opsomming van mogelijke requirements
• Business requirements : wat willen we bereiken
• Proces requirements : hoe gaan we het doen
• Functionele reqiurements : systeem vereisten
• Niet Functionele reqiurements : kwaliteitsvereisten(bijvoorbeeld ISO)
• Transitie requirements : make-or-buy, vervangen of behouden, legacy, etc.
• Leveranciers requirements : aan welke eisen moeten uw leveranciers voldoen
Het bepalen van de requirements is een intensief traject waarvoor integraal bronnen en stakeholders geraadpleegd en geconsulteerd worden. Van systeem architectuur, beleid, kwaliteitsmanagement, processen tot noodzakelijke innovaties.
Deze aanpak in combinatie met workshops en bovenstaande aandachtspunten helpen u op weg te voldoen aan de eisen en wensen van de gebruikers.
Waarom QbitGovernance?
Wij gaan terug naar de basis en onderzoeken samen met u waarom de door u te maken requirement keuzes relevant zijn. Digitalisering, Robotisering, Artificial Intelligence, Internet of Things, et cetera groeien de komende decennia spectaculair en hebben impact op elke organisatie, dus ook die van u. Wat ons betreft zijn een solide Data, IT & Governance structuur hierin essentieel.
QbitGovernance heeft jarenlange ervaring het vertalen van Data, IT & Governance uitdagingen in oplossingen. Waar mogelijk implementeren wij samen met u een Scrum aanpak. Wij handelen en denken leveranciers onafhankelijk en zijn actief in vrijwel alle profit en non-profit sectoren, van mkb tot (zorg)instellingen en de overheid.
