Wat zijn de verschillen tussen agile epics en gebruikersverhalen? Gebruikersverhalen zijn een fundamenteel onderdeel van elke agile ontwikkeling. Het zijn lichtgewicht vereisten die nieuwe functionaliteit vertegenwoordigen die waarde levert aan zakelijke belanghebbenden, waaronder eindgebruikers. Zij zijn de bouwstenen die prioriteit krijgen op de product achterstand en gebracht in sprints, en ze richten het ontwikkelingsteam op het leveren van zakelijke waarde.
dus wat is een epic?,
als je rondhangt bij agile ontwikkelaars, zul je die term ook van tijd tot tijd horen. Ze klinken net als gebruikersverhalen. Maar zijn ze dat? In dit bericht, Ik zal duiken in de verschillen tussen epics en user stories: wat ze zijn, hoe ze gerelateerd zijn, en waarom je nodig hebt zowel voor uw agile ontwikkelingsprojecten.
Wat is een gebruikersverhaal?
eerder heb ik een diepgaande kijk gedeeld op wat gebruikersverhalen zijn en hoe ze worden gemaakt.,
om samen te vatten, begint een gebruikersverhaal met een eenvoudig statement in de vorm van:
als a , Ik wil , dus ik
aan dit statement voegen we een verscheidenheid aan details toe, bestaande uit de acceptatiecriteria en de discussienota ‘ s van het ontwikkelteam.
zodra deze elementen allemaal op hun plaats zijn, wordt het gebruikersverhaal als klaar voor productie beschouwd. Het kan dan worden opgenomen in de volgende sprint… als het hoog genoeg prioriteit door de producteigenaar.
Wat is een Epic?
een epic is een groot gebruikersverhaal., De term wordt vaak gebruikt om ongelooflijk lange verhalen te beschrijven, zoals Paradise Lost, geschreven door de 17e-eeuwse Engelse dichter John Milton. Milton ‘s” epische ” gedicht bestond oorspronkelijk uit meer dan tien volumes met meer dan tienduizend verzen.
wat betreft softwareontwikkeling, hoe groter het verhaal, hoe groter de kans dat je naar een epos kijkt. Dit is het belangrijkste verschil tussen agile epics en gebruikersverhalen.
dat is het. Niets bijzonders hier. Geen behoefte om vast te zitten in knopen proberen te achterhalen, ” moet dit een epos of een verhaal?,”Als het iets is dat zakelijke waarde biedt en moet worden op het product achterstand, het is een gebruiker verhaal. Maar het kan ook een episch zijn, want het is groot.
dus wat betekent” groot ” eigenlijk?, In de jaren dat ik heb met behulp van Scrum, de beste twee definities die ik heb gevonden zijn:
- Een epische is een verhaal dat groter is dan 8 story points
- Een epische is een verhaal dat niet kan worden voltooid in een sprint
ik denk dat de tweede definitie is beter, omdat het niet afhankelijk is van uw gebruik van story points voor de raming (al kun je lezen waarom ik liefdesverhaal punt te schatten, en onafhankelijk van je team velocity.
Epics kunnen variëren van gebruikersverhalen die bijna klein genoeg zijn om in een sprint te passen, tot enorme “high level” epics die grote functies bevatten.,
bekijk mijn boek The Epic Guide to Agile voor meer informatie!
begin met Epics voor gebruikersverhalen
wanneer u voor het eerst begint met het plannen van een agile ontwikkelingsproject, zullen al uw gebruikersverhalen waarschijnlijk in epische vorm zijn. Dan, als de producteigenaar begint te prioriteren, zal de belangrijkste van die epics worden opgesplitst, naar beneden, naar beneden in veel kleinere gebruikersverhalen.
de eigenaar van het Product geeft dan prioriteit aan die verhalen en de hoogste prioriteit zal het maken in de volgende sprint.,
een van de belangrijkste voordelen van EPIC ‘ s is dat ze ervoor zorgen dat uw product achterstand niet rommelig wordt. Bedenk wat er zou gebeuren als je elk van je epics zou breken in Sprint-sized gebruikersverhalen aan het begin van een project. Ten eerste, uw product achterstand zou ongelooflijk log zijn, waardoor het werk van uw product eigenaar van prioritering veel moeilijker. Ten tweede, de tijd die nodig is om al die gebruikersverhalen te schrijven en te bespreken zou zijn als … nou ja, traditionele projectontwikkeling.,
door de meeste van uw gebruikersverhalen in epische vorm te houden, maakt u het veel gemakkelijker voor de producteigenaar om de product achterstand te beheren. Nog belangrijker, u houdt uw development team van het verspillen van hun tijd hashing uit een groot aantal gebruikers verhalen die misschien nooit worden geprioriteerd op alle. Aan het begin van een project, ik graag een product backlog bestaat uit 50 tot 75 verdiepingen idealiter, en niet meer dan 100 op de high-end.,
wanneer uw Epics moeten worden afgebroken
er is maar één geschikte tijd om een epic op te splitsen in stukjes gebruikersverhaal van sprintformaat: wanneer de eigenaar van het product het gevoel heeft dat een epic de top van de achterstand nadert. Op die manier is de beweging van een epos naar de top van de achterstand een ander verschil tussen agile epics en gebruikersverhalen.
totdat dat gebeurt, zijn uw gebruikersverhalen beter af in epische vorm. Maar zodra een epic klimt in de bovenste regionen van uw product achterstand, is het tijd om te beginnen met het afbreken van het naar beneden.,
u hoeft het hele epic echter niet op te splitsen in stukjes ter grootte van een sprint. In feite zou je dat niet moeten doen. sommige van de gebruikersverhalen in dat epos zullen hogere prioriteiten hebben dan andere. En sommige van de gebruikersverhalen die je in dat epic zult vinden, zullen veel lager zijn dan andere prioriteiten op je lijst.
je wilt je heldendaden wegscheuren zoals een beeldhouwer stenen wegschiet-niet om iets nieuws te maken, maar om de belangrijke onderdelen die erin verborgen zijn te onthullen. Zoals Michelangelo ooit zei: “elk blok steen heeft een standbeeld erin en het is de taak van de beeldhouwer om het te ontdekken.,”
dus, ook, heeft uw product eigenaar nodig om weg te chip op uw epics om de belangrijkste gebruikers verhalen in te ontdekken. Die – en alleen die-zijn de verhalen van gebruikers die moeten worden uitgewerkt, besproken, en klaar gemaakt voor een sprint.
en nadat je een aantal gebruikersverhalen uit een epic hebt gechipt, wat gebeurt er dan met de rest? Er gebeurt niets mee… het blijft in de product achterstand als een epos. Na de volgende sprint, uw product eigenaar kan ervoor kiezen om chip uit wat meer gebruikers verhalen van het., Of misschien verliest het epic enige relevantie zonder die belangrijke onderdelen en zakt het verder naar beneden op de prioriteitenlijst.
hoe dan ook, de beslissing over wat te doen met een epic zal worden gemaakt op basis van de positie van dat epic binnen de product achterstand en niets anders.
Epics and User Stories: een Tandem van efficiëntie
dus daar heb je het.
Wat is een epic? Het is een grote gebruiker verhaal dat is niet klaar voor – en kan niet passen in – een productie sprint., U slaat epics in uw product achterstand omdat ze geven u een enorme efficiëntie boost, het houden van uw scrum development team uit de buurt van lagere prioriteit afleiding.
en wanneer een epic boven aan uw prioriteitenlijst komt, hoeft u het geheel niet op te splitsen. Je breekt gewoon zoveel gebruikersverhalen met hoge prioriteit uit als je nodig hebt. Vervolgens geeft de producteigenaar prioriteit aan zowel de voltooide gebruikersverhalen als de restanten van het epic in de product achterstand.
op deze manier zorgt het combineren van epics en user stories voor een tandem van efficiëntie voor uw Scrum development team., Hoewel vergelijkbaar van aard, epics en hun kleinere, sprint-sized gebruiker verhalen dienen twee duidelijk verschillende doeleinden.
Als u moeite heeft gehad met het snel realiseren van bedrijfswaarde met uw productontwikkelingsteams, neem dan vandaag nog contact met ons op.