In dit inleidende-Level artikel kijken we naar de mechanica van een Sprint, en naar hoe teamleden geacht worden samen te werken om een release-kwaliteit verhoging te produceren.

de eerste dag: sprintplanning

het hele team, inclusief de producteigenaar, komt bijeen op de eerste dag van de Sprint en voert een Sprintplanningssessie uit. Dit is het allereerste wat er gebeurt zodra de Sprint begint.

voorbereiding

sprintplanning moet worden voorbereid. De belangrijkste voorbereiding is ervoor te zorgen dat de product achterstand is verfijnd tot een passend niveau van detail, met schattingen en acceptatiecriteria (dit is het doel van product achterstand verfijning). Vervolgens moet de eigenaar van het Product het werk aan de product achterstand hebben besteld, en hebben een algemeen idee van hoe om te onderhandelen over een waardevolle Sprint doel met het team. De opties voor het onderhandelen over een doel hadden ook moeten worden overwogen tijdens de verfijning, en weerspiegeld in achterstand bestelling. Ook moet de ploeg een idee hebben van hun capaciteit voor deze Sprint, dat wil zeggen, hoeveel werk ze denken dat ze op kunnen nemen. Zij kunnen hun ervaring met eerdere Sprints gebruiken om hen te helpen de omvang van dit budget vast te stellen.

plan eerst de waarde die zal worden geleverd

elke Sprint moet resulteren in een waardevolle toename van voltooid werk, fit en klaar voor onmiddellijke release. De eigenaar van het Product is volledig verantwoordelijk voor wat “waarde” betekent, en moet de product achterstand hebben besteld op een zodanige manier dat de waarde kan worden gemaximaliseerd door het team, sprint-per-sprint. Het eerste wat de ploeg moet doen is dus om te plannen welke items uit de product achterstand moet worden gewerkt in deze Sprint, zodat de beste waarde kan worden geleverd tegen het einde van het.

om dit te doen, werkt het team samen met de producteigenaar om de meest waardevolle items te selecteren uit de product achterstand die past bij hun verwachte capaciteit voor de Sprint. Houd in gedachten dat elk item op het product achterstand zou moeten zijn gegeven een schatting door het team, zodat ze zullen ongeveer weten hoeveel werk waarschijnlijk betrokken zijn.

zorg ervoor dat u het eens bent over een sprintdoel

deze selectie van werk moet samenhangend zijn, en niet alleen een groepering van niet-gerelateerde en ongelijksoortige items. Vergeet niet dat een Sprint is een tijd-boxed kans om iets belangrijks te bereiken. Aan het eind van de Sprint kan bijvoorbeeld een samenhangend kenmerk zijn bereikt, of een aanzienlijk risico is beperkt. Het sprintdoel is een eenvoudige uitdrukking van dit doel, van de overkoepelende betekenis van het geselecteerde werk en de samenhang achter de selectie.

een goede Sprintdoelstelling zal het team in staat stellen om focus en inzet te tonen, en samenwerking en de herplanning van het werk mogelijk te maken, zodat het wordt bereikt.

volgende plan hoe het werk zal worden gedaan

een Sprint Backlog is meer dan alleen een selectie van werk met een einddoel in het achterhoofd. Het is ook een plan voor hoe dat doel zal worden bereikt, en hoe het bijbehorende werk zal worden uitgevoerd. Dit kan worden gedaan door het identificeren en bestellen van de technische taken die waarschijnlijk betrokken zijn. In feite is de Sprint Backlog een plan voor het bereiken van het Sprint doel, en een prognose van het werk dat zal moeten worden gedaan.

de eigenaar van het product hoeft niet aanwezig te zijn voor dit deel van de sprintplanning, aangezien het aan het team is om deze prognose op technisch niveau te plannen. Echter, de eigenaar van het Product moet beschikbaar zijn, zelfs al is het maar op afstand, om eventuele vragen van het team te beantwoorden, en om eventuele verduidelijking die nodig kan zijn over de omvang van het werk. Als er meer dan één release wordt verwacht tijdens de Sprint, moet dit worden overeengekomen met de PO en verantwoord in de Sprint achterstand.

tegen het einde van de sprintplanning moet een team er zeker van zijn dat het een goede prognose heeft gemaakt van het werk dat nodig is om het sprintdoel te halen. Het zal dat plan hebben vastgelegd in de Sprint achterstand die de ploeg volledig bezit. Het team moet onmiddellijk kunnen beginnen met de uitvoering van dat plan en met een duidelijk begrip – zoals een sprint Burndown – van hoeveel werk er op een bepaald punt blijft.

elke dag, elke dag

zodra het team hun Sprint Backlog heeft gepland, kunnen ze aan de slag. Als ze dingen hebben gepland als taken, zullen ze samenwerken met elkaar, als een team, om ervoor te zorgen dat die taken worden voltooid. Ze zullen in staat zijn om hun vooruitgang te volgen met behulp van hun task board en hun Sprint Burndown van het werk resterende.

elk teamlid zal het Scrum Task Board En De Sprint Burndown up-to-date houden, zodat anderen op de informatie kunnen vertrouwen. Een informatie radiator moet altijd de waarheid vertellen.

houd elke werkdag een Scrum

, tegelijkertijd zal het ontwikkelingsteam samenkomen en plannen wat ze zullen doen om hen dichter bij het sprintdoel te brengen. Deze bijeenkomst heet de Daily Scrum en mag nooit meer dan 15 minuten duren.

alleen leden van het ontwikkelteam mogen deelnemen, aangezien het werkplan volledig van hen is. Het is een tijd-boxed kans om de Sprint achterstand opnieuw te plannen als gevolg van nieuwe ontdekkingen en lessen geleerd tijdens de Sprint. Het hele team moet meedoen. Elk teamlid moet kunnen verklaren:

• wat ze gisteren hebben gedaan om de ploeg te helpen het sprintdoel te bereiken
• wat ze vandaag van plan zijn te doen om de ploeg te helpen het sprintdoel te bereiken
• eventuele belemmeringen die hen in de weg staan

tegen het einde van de dagelijkse Scrum moet de ploeg een duidelijk plan hebben voor de komende 24 uur en inzicht hebben in de manier waarop ze moeten samenwerken om dit te bereiken. Ze moeten ook een lijst hebben van alle belemmeringen die de aandacht van de Scrum Master vereisen.

verfijn de Product Backlog

In Scrum is Product Backlog verfijning geen formele gebeurtenis, maar een voortdurende activiteit – het proces van het toevoegen van details, volgorde en schattingen aan Product Backlog Items zoals gebruikersverhalen. Het is aan Scrum Teams zelf om te beslissen hoe vaak ze dit doen, hoewel het zeker een goed idee voor hen is om verfijning in hun dagelijkse routine te bouwen. Verfijning mag niet meer dan 10% van de totale tijd van een ploeg in beslag nemen tijdens een Sprint. Voor de meeste teams kan een half uur per dag voldoende zijn, hoewel sommigen er de voorkeur aan geven om een paar keer per week een uur of twee door te brengen. Het belangrijkste is om ervoor te zorgen dat de product achterstand tijdig wordt verfijnd, zodat Sprint Planning kan plaatsvinden zonder belemmering. Het hele team, inclusief de producteigenaar, moet deelnemen.

een verfijningssessie begint meestal wanneer de eigenaar van het Product de huidige product achterstand aan het team presenteert. De achterstand kan worden gehouden in een aantal vormen, zoals een elektronische Scrum Board of andere samenwerking tool, of het kan gewoon een spreadsheet. Een projector of gedeeld scherm kan erg handig zijn.

begint het team aan de bovenkant van de Product Backlog en werkt het naar beneden, waarbij elk item op zijn beurt wordt verfijnd. Ze zullen elk ervan onderzoeken en de reikwijdte ervan bespreken, en de acceptatiecriteria die nodig zijn voor de voltooiing ervan. Elk item zal dan worden geschat met behulp van een techniek zoals het plannen van Poker. Een groot item kan worden opgesplitst in kleinere die meer detail te vangen. Epics kan worden ontbonden in de gebruiker verhalen, bijvoorbeeld.

het team stopt zodra de time-box van de sessie op is. Ze zullen opnieuw beginnen waar ze waren gebleven de volgende keer, uiteindelijk weer te beginnen bij de top zodat de achterstand wordt bijgehouden.

werk altijd samen

in agile praktijk werken teamleden nooit geïsoleerd – als ze dat wel deden, zouden ze geen team zijn. In feite, teamwork is zo belangrijk dat de rol is ontwikkeling Team in plaats van ontwikkelaar.

Dit betekent dat elk lid van het ontwikkelingsteam gedurende de dag moet samenwerken met zijn of haar collega ‘ s, aangezien zij gezamenlijk verantwoordelijk zijn voor de voortgang van de werkzaamheden. Eventuele problemen of mislukkingen zijn gezamenlijk eigendom van het team, evenals hun successen. Samenwerking is niet iets dat beperkt is tot evenementen zoals de dagelijkse Scrum, maar geldt voor alles wat de ploeg doet gedurende elke hele Sprint.

voorbeelden van samenwerking zijn::

• peers helpen om werk in uitvoering te voltooien alvorens nieuw werk uit een achterstand in te voeren
• Paarprogrammering, zoals om beurten het toetsenbord gebruiken en elkaars werk helpen en controleren
• Peer review
• om hulp vragen, en erop gebrand zijn om het
• te geven naar waar het werk is en te helpen, in plaats van te wachten tot het werk aan hen wordt overgedragen
• ervoor te zorgen dat al het werk in feite aan de definitie voldoet of done
• calling a Scrum in order to solve problems which reply the team ‘ s immediate attention
• de Scrum Master zodat ze tijdig kunnen worden afgehandeld
• een Scrum Task board en burndown chart bijwerken zodat de informatie up-to-date is en kan worden vertrouwd op
• vaardigheden en kennis delen

de laatste dag: Review en retrospectief

Houd een Sprint Review

als een team heeft samengewerkt efficiënt, ze zullen hebben samengewerkt om de sprint doel te bereiken, het beheer van eventuele risico ‘ s en het aanpassen van hun plannen indien nodig. Ze zullen tijdens de Sprint controle hebben getoond door middel van een gelijkmatige burndown van het resterende werk, waarbij elk lid het zag als hun persoonlijke verantwoordelijkheid om te helpen bij het voltooien van het werk in uitvoering. Ze hebben een waardevolle toename om te demonstreren aan de producteigenaar en eventuele uitgenodigde stakeholders. Een beoordeling is iets waar een team naar moet uitkijken.

het is ook iets waar een team zich op moet voorbereiden. Er moet voldoende tijd worden uitgetrokken voor een demonstratie van het uitgevoerde werk. Taken kunnen worden gepland op een Sprint achterstand voor dit doel, om ervoor te zorgen dat de herziening doet recht aan het werk en de waarde die nu beschikbaar is. Ook, als de producteigenaar denkt dat het een goed idee zou zijn om stakeholders uit te nodigen, dan moeten die uitnodigingen zijn verzonden. De beoordeling is een gelegenheid om het werk dat is gedaan te vieren en om hun prestaties te laten zien, dus vertrouwen is geïnspireerd en een voortdurende investering in het team kan gerechtvaardigd zijn.

een Sprint-beoordeling is ook een mogelijkheid om te inspecteren en aan te passen. Het is een goed moment voor de producteigenaar om uit te leggen hoe goed het product presteert, om feedback uit de eerste hand te krijgen van alle uitgenodigde partijen, en om lessen te trekken die kunnen worden gebruikt om de product achterstand verder te verbeteren. Als er om welke reden dan ook geen werk is voltooid, dan zal dit ook worden herzien en opnieuw geschat op de product achterstand voor mogelijke planning in toekomstige sprints.

voer vervolgens een Sprint Retrospective uit

in de Sprint Review werd gekeken naar het Product en de geleverde waarde, naar het werk dat is gedaan, en eerlijk en openhartig naar elk werk dat niet is gedaan, ongeacht de reden.het volgende wat je moet doen is een terugblik op de Sprint uitvoeren. Een retrospectief bekijkt het proces dat het team volgt. Werken ze zo effectief als ze kunnen? Het is over het algemeen het beste om de retrospectieve onmiddellijk na de beoordeling te houden, omdat de eerste ideeën kan introduceren voor overweging in de laatste.

het hele ontwikkelteam, de producteigenaar en de Scrum Master moeten allemaal aanwezig zijn bij de retrospectieve, omdat iedereen gezamenlijk verantwoordelijk is voor het succes van het werk van het team. Het is echt belangrijk om een gratis en open sessie die krijgt om de kern van eventuele problemen en identificeert acties die zullen helpen om ze op te lossen. Een retrospectieve kan beginnen met de volgende verklaring:

” ongeacht wat we ontdekken, we begrijpen en geloven echt dat iedereen het beste werk deed dat ze konden, gezien wat ze op dat moment wisten, hun vaardigheden en capaciteiten, de beschikbare middelen, en de huidige situatie.”

In een” Retro ” heeft iedereen een gelijke stem. Een aanpak die de Scrum Master kan faciliteren, is het identificeren van:

• dingen die goed gingen
• dingen die niet zo goed gingen
• ideeën voor verbetering
• Shout-outs voor teamleden die iets uitzonderlijks deden

Het instellen van een tijdslijn kan de herinneringen van deelnemers aan belangrijke gebeurtenissen tijdens de Sprint helpen joggen.