1.Hierarchy binnen Getscope
Binnen Getscope werken we met de volgende (Agile) structuur.
- Epics / Categorieën
- User stories
- Tasken
2.Wat is een user story?
Een User Story is een korte beschrijving gebaseerd op de wensen en behoeften van de (eind)gebruiker. Een User Story is geen functionele beschrijving maar maakt duidelijk wat een eindgebruiker wil of nodig heeft en waarom dat nodig is.
Bijvoorbeeld:
1.Als manager wil ik een overzicht kunnen opvragen van alle lopende projecten binnen mijn organisatie, zodat ik kan zien wat de werkdruk is.
2.Als geregistreerde gebruiker wil ik een nieuw wachtwoord kunnen aanvragen zodat ik toch toegang krijg als ik mijn wachtwoord vergeten ben.
3.Als student wil ik mijn cijfers online kunnen bekijken, zodat ik sneller weet of ik mijn examen heb gehaald.
User Stories worden meestal geschreven door de Product Owner en staan dan op de Backlog. Dit is de werkvoorraad van je product. Deze user stories worden vervolgens opgepakt door het Team. Het opleveren van een User Story levert een stukje “waarde” op voor de eindgebruiker. Alle User Stories op de Backlog samen vertegenwoordigen de totale “waarde” die binnen een project kan worden opgeleverd.
Een voorbeeld van een user story binnen Getscope:
Een korte introductie in ScrumÂ
Wil je meer informatie over Scrum en hoe het werkt, bekijk dan deze Youtube link;
Inleiding tot Scrum – 7 minuten: Inleiding tot scrum in 7 minuten
Introduction to scrum in 7 minutes (Inleiding tot Scrum – 7 minuten)
3.Wat zijn Epics (of categorieën) binnen Getscope en hoe gebruik je ze?
User Stories zijn er in verschillende formaten. Een User Story beperkt zich in de meeste gevallen tot een specifiek onderdeel van het product. Een grote User Story wordt een “Epic” genoemd. Een “Epic” is per definitie te groot om in één sprint op te pakken en op te leveren. Daarvoor moet de Epic eerst worden opgeknipt in kleinere User Stories, die klein genoeg zijn om elk in één sprint te passen.
Binnen Getscope kun je Epics gebruiken op de Agile manier, maar je kunt er ook categorieën in maken waarin je user stories maakt.
Hieronder een voorbeeld van het gebruik van Epics / Categorieën binnen Getscope:
4.Wat is de Backlog en hoe gebruik je het.
De Backlog in Getscope is bedoeld voor de user stories die tijdens de ontwikkeling van het product moeten worden uitgevoerd. Over het algemeen maakt de Product Owner een indeling naar prioriteit of business value, met de belangrijkste items bovenaan. Deze taken moeten als eerste worden opgepakt.
Vlak voor de start van een nieuwe sprint zorgt de Product Owner ervoor dat een aantal gedetailleerde User Stories klaar zijn, zodat het team aan de slag kan met de items die de hoogste prioriteit hebben.
Getscope werkt met de MoSCow-methode binnen de Backlog
Wat is de MoSCoW Methode?
technologieën. Iedereen binnen een organisatie wil altijd alles direct implementeren en dat is praktisch onmogelijk. Er zijn verschillende hulpmiddelen om prioriteiten te stellen. De MoSCoW-methode is er een van. Het is bedacht door Dai Clegg die de MoSCoW-methode bedacht binnen het bedrijf Oracle.
MoSCoW is een combinatie van beginletters die ergens voor staan. De 2x O zijn ingevoegd om het woord “moscow” leesbaar te maken, zonder betekenis.
De M staat voor Must-haves,
De S staat voor Should-haves
De C staat voor Could-haves
De W staat voor Won’t haves of Would-haves.
Backlog met MoSCoW formaat in Getscope. Je kan de namen van de Backlog-kolommen wijzigen in de ‘instellingen’ van je project.
Voordat je met de MoSCoW-methode begint, kunt ujehet beste beginnen met het specificeren van je Backlog. Dit doe je met het hele team waarbij iedereen input geeft. Om te voorkomen dat je onrealistische eisen stelt, kun je het beste eerst een reeks prio’s opstellen. En ze in te delen in een van de volgende categorieën:
M – Must-haves
Dit betreft de minimumeisen die vooraf worden gesteld en waaraan het eindresultaat moet voldoen. Zonder deze eis mislukt het project en kan het product niet meer worden gebruikt. Must-haves zijn essentieel. MUST wordt ook wel uitgelegd als het acroniem dat staat voor Minimum Usable SubseTs.
Voorbeeld: Studenten hebben een eindexamenopdracht om een auto te ontwerpen en te maken die minstens (minimale set eisen) kan rijden. De must-have is in dit geval dat de auto aan het eind van het studiejaar moet kunnen rijden.
S – Should-haves
Dit zijn aanvullende en zeer gewenste eisen, die een hoge prioriteit hebben, maar geen vereiste zijn voor een bruikbaar eindproduct. Zonder dat aan deze eisen wordt voldaan, kan het product nog steeds worden gebruikt en bij naleving krijgt het product alleen toegevoegde waarde. Afhankelijk van de tijd kunnen deze eisen altijd later worden aangepakt.
Voorbeeld: De studenten willen de auto misschien voorzien van een trekhaak (should-have), maar als de auto ook zonder trekhaak kan rijden, is hun project geslaagd.
C – Could-haves
Als er tijd voor is, kan aan deze eisen altijd worden voldaan. Zo niet, dan is dat geen probleem en heeft het geen nadelige gevolgen voor het eindresultaat. De could-haves hebben minder prioriteit dan de should-haves. De optie wordt alleen opgenomen als er werkelijk voldoende tijd is om het te realiseren. Het wordt ook wel “nice to have” genoemd en het is meer een wens dan een harde eis.
Voorbeeld: Studenten willen misschien een revolutionaire muziekgadget in de auto installeren. Geen belangrijke (examen)eis, maar wel leuk als het ze lukt.
W – Won’t-haves (en would-haves)
Dit betreft toekomstwensen die vaak niet mogelijk zijn of veel tijd kosten om te realiseren. Als het niet mogelijk is, dan is het verstandig er geen energie in te steken. Is realisatie wel mogelijk dan zal er veel tijd (en geld) in geïnvesteerd moeten worden en is er sprake van een would-have. Vaak worden would-haves opgenomen in een vervolgtraject.
Voorbeeld: Het is voor de studenten niet noodzakelijk dat de auto daadwerkelijk de weg op gaat. Het is een studieobject. Als men toch op de openbare weg wil rijden, moet de auto een carrosserie hebben en aan veiligheidseisen voldoen. Ook zal via een proces toestemming moeten worden gevraagd aan de Dienst Wegverkeer.
Indien je meer informatie nodig hebt over het prioriteren volgens de MoScOW Methode bekijk dan deze video: Prioritisation using MoSCoW
5.Wat is een sprint en hoe werkt dat binnen Getscope.
Een sprint, een gedefinieerde tijdsperiode, vormt de basis van een Scrum-project. Het doel van scrummen is: “zo snel mogelijk een product opleveren dat voldoet aan alle vooraf overeengekomen criteria, zonder de continue ontwikkeling en het voortdurend inspelen op veranderingen uit het oog te verliezen.”
Elke sprint duurt altijd even lang, meestal tussen 1 en 6 weken. Dit is enigszins afhankelijk van het project. Een softwareontwikkelingsproject van een jaar heeft meestal sprints van 2-4 weken en een marketingcampagne van een paar maanden meestal een sprint van een week.
Een sprint doorloopt de volgende stappen:
Sprint Planning Meeting: In deze vergadering, die maximaal 8 uur duurt, bespreekt het hele team wat er in de komende sprint moet gebeuren. Samen kiezen ze taken uit de Product Backlog, die door de Product Owner op basis van prioriteit is gerangschikt. Na deze selectie wordt bepaald hoe deze taken zullen worden uitgevoerd.
Sprint Review: Tijdens de Sprint Review wordt het (deel)project gepresenteerd aan alle stakeholders, met ruimte voor feedback. Ook geeft het Scrum Team inzicht in wat ze in de volgende sprint willen aanpakken.
Sprint Retrospective: Na het opleveren van een (deel)product wordt de afgelopen sprint samen met alle leden van het Scrumteam geëvalueerd. De Sprint Retrospective wordt na elke sprint als vaste bijeenkomst gepland, zodat verbeterpunten meegenomen kunnen worden naar de volgende sprint.
Binnen Getscope heb je de mogelijkheid om een sprint in zijn geheel voor te bereiden. Je kunt de sprint in zijn geheel voorbereiden en voorbereiden voordat de nieuwe sprint eindigt. Met de Backlog aan de linkerkant kun je de aangemaakte user stories uit de Backlog op je bord zetten. Als je de sprint hebt aangemaakt kun je hem aanzetten via de knop ‘Start’, ‘Stop’.
