Open vragen Flashcards
U neemt als deskundige deel in een systeemontwikkelingsproject volgens de scrummethodiek.Een van de stakeholders vraagt aan u uitleg over de kenmerken van product backlog refinement en stelt u de volgende vragen:
- Hoe voegt product backlog refinement waarde toe aan het projectresultaat?
- Uit welke activiteiten bestaat product backlog refinement voor de product owner (noem er twee) en voor het developmentteam (noem er één)?
- Hoeveel procent tijdsbesteding van de sprint mag dit kosten van het developmentteam?
- Toegevoegde waarde aan het projectresultaat:
Product Backlog Refinement (PBR) voegt waarde toe aan het projectresultaat op verschillende manieren. Ten eerste helpt het bij het verfijnen en verduidelijken van product backlog-items, waardoor ze begrijpelijker worden voor het developmentteam. Dit draagt bij aan een beter begrip van de vereisten, wat resulteert in een nauwkeuriger inschatting van de inspanning en betere planning. Daarnaast biedt PBR ruimte voor voortschrijdend inzicht en nieuwe informatie, waardoor het mogelijk is om prioriteiten aan te passen en de product backlog aan te passen aan veranderende omstandigheden. - Activiteiten voor de Product Owner en het Development Team:Voor de Product Owner:
Prioriteren van de backlog-items: De Product Owner is verantwoordelijk voor het bepalen van de prioriteiten binnen de product backlog. Dit houdt in dat ze continu beoordelen welke backlog-items de hoogste waarde hebben voor de klant en het bedrijf.
Refinen van backlog-items: De Product Owner werkt samen met het developmentteam om de backlog-items te verfijnen en te verduidelijken. Dit omvat het stellen van vragen, het aanpassen van de beschrijvingen en het zorgen voor een duidelijk begrip van de vereisten.
3. Voor het Development Team:
Schatting en planning: Het developmentteam is betrokken bij het inschatten van de inspanning die nodig is voor elk backlog-item. Ze geven input over de complexiteit en de tijd die nodig is om een item te voltooien. Dit helpt bij het plannen van de komende sprints.
Tijdsbesteding van het Development Team:
De product backlog refinement-activiteiten mogen normaal gesproken ongeveer 5-10% van de totale capaciteit van het developmentteam in beslag nemen. Dit percentage kan variëren afhankelijk van factoren zoals de mate van duidelijkheid van de backlog-items en de complexiteit van het project. Het is echter belangrijk dat deze activiteiten niet te veel tijd in beslag nemen, zodat het team zich kan blijven concentreren op het leveren van werkende software tijdens de sprints.
- Om te voldoen aan de principes van het Agile Manifesto zijn teams nodig die een crossfunctionele/multidisciplinaire samenstelling hebben. Leg uit waarom dit nodig is.
- Wat is osmotische communicatie en hoe wordt het toegepast?
- Een stakeholder vraagt aan de scrum master of hij de volgende ochtend mag participeren tijdens de daily scrum. Wat moet het antwoord van de scrum master zijn?
- Wie heeft de verantwoordelijkheid over de uitvoering van de daily scrum?
- Crossfunctionele/multidisciplinaire teams in het Agile Manifesto:
Het Agile Manifesto benadrukt het belang van individuen en interacties boven processen en tools. Het vormt een leidraad voor het ontwikkelen van software op een flexibele en responsieve manier. Crossfunctionele/multidisciplinaire teams zijn nodig omdat ze verschillende expertisegebieden samenbrengen in één team. Dit zorgt voor een betere samenwerking en communicatie tussen teamleden met diverse vaardigheden (bijvoorbeeld ontwikkeling, testen, ontwerp, etc.), waardoor het team als geheel meer in staat is om te reageren op veranderende vereisten. Een dergelijke samenstelling maximaliseert de flexibiliteit van het team om te leveren wat de klant nodig heeft, omdat het team in staat is om taken end-to-end uit te voeren zonder afhankelijk te zijn van externe specialisten. - Osmotische communicatie:
Osmotische communicatie verwijst naar het informele, contextuele begrip dat ontstaat wanneer teamleden zich fysiek dicht bij elkaar bevinden. In een osmotische communicatieomgeving kunnen teamleden informatie opvangen, zelfs als ze niet rechtstreeks bij een gesprek betrokken zijn. Dit concept benadrukt de waarde van fysieke nabijheid voor spontane, ongeplande communicatie, waardoor teamleden op de hoogte blijven van wat er gaande is. Het stimuleert het delen van kennis en het snel oplossen van problemen. Osmotische communicatie wordt vaak bevorderd door open kantooromgevingen of virtuele communicatiemiddelen die constante interactie mogelijk maken. - Deelname aan de Daily Scrum:
De Daily Scrum is een evenement voor het developmentteam om de voortgang te bespreken en de dag te plannen. Stakeholders worden normaal gesproken niet uitgenodigd om deel te nemen aan de Daily Scrum, omdat het gericht is op het team zelf. De scrum master moet uitleggen dat de Daily Scrum in principe voor het developmentteam is, maar dat zij open staan voor het delen van informatie na de bijeenkomst. Als de stakeholder specifieke zorgen heeft, kan de scrum master alternatieve communicatiekanalen aanbevelen om die zorgen te bespreken. - Verantwoordelijkheid voor de uitvoering van de Daily Scrum:
De Daily Scrum wordt uitgevoerd door het developmentteam. Het is een zelforganiserend evenement waarin teamleden samenwerken om hun voortgang te bespreken en te plannen voor de komende 24 uur. De scrum master heeft geen leidende rol tijdens de Daily Scrum, maar faciliteert het evenement en kan obstakels helpen verwijderen. Het is de verantwoordelijkheid van het developmentteam om de bijeenkomst te leiden en ervoor te zorgen dat het doel, namelijk het afstemmen van het team op de voortgang van het werk, wordt bereikt.
De eerste sprint van een scrumproject is afgerond. Er waren tien items gepland op de sprint backlog. Aan het einde van de sprint is het volgende resultaat opgeleverd:
Item Storypoints % done 1 34 100 2 38 100 3 23 100 4 42 100 5 30 100 6 35 100 7 28 60 8 25 100 9 36 40 10 40 20
- Bereken de velocity van het developmentteam van deze sprint.
- Het totale project is begroot op 1.840 storypoints. Bereken
hoeveel sprints er nodig zijn uitgaande van de velocity van de
eerste sprint. - Welke items uit dit voorbeeld worden tijdens de sprint review
aan de product owner en andere stakeholders
gedemonstreerd?
- Velocity berekenen:
De velocity van een developmentteam wordt berekend door de storypoints van de voltooide items in een sprint op te tellen. In dit geval zijn de items 1 tot en met 8 voltooid, dus de velocity is:Velocity=∑i=18StorypointsiVelocity=∑i=18StorypointsiVelocity=34+38+23+42+30+35+28+25=255Velocity=34+38+23+42+30+35+28+25=255
De velocity van het developmentteam voor deze sprint is 255 storypoints.
- Aantal benodigde sprints berekenen:
Als het totale project begroot is op 1.840 storypoints en we de velocity van de eerste sprint weten (255 storypoints), kunnen we het aantal benodigde sprints berekenen:
Aantal sprints=Totaal begrote storypointsVelocity per sprintAantal sprints=Velocity per sprintTotaal begrote storypoints
Aantal sprints=1.840255≈7,22Aantal sprints=2551.840≈7,22
- Omdat je geen fractionele sprints hebt, moet je afronden naar boven. Dus, uitgaande van de velocity van de eerste sprint, zijn ongeveer 8 sprints nodig om het totale project af te ronden.
Items gedemonstreerd tijdens de sprint review:
ijdens de sprint review worden over het algemeen de voltooide items gedemonstreerd. In dit geval zouden de items 1 tot en met 8 worden gedemonstreerd, omdat ze allemaal 100% voltooid zijn. De items 9 en 10, die respectievelijk 40% en 20% voltooid zijn, worden mogelijk niet gedemonstreerd omdat ze nog niet voltooid zijn of niet genoeg waarde hebben om te tonen aan de stakeholders.
- Bedenk vijf voorbeelden om op te nemen in een Definition of
Done. - Stel, u bent ober in een restaurant. Tot nu toe werden
bestellin gen van de gasten altijd op een kladblokje
geschreven en naar de keuken gebracht. Het restaurant gaat
automatiseren. Alle obers krijgen een mobiel apparaat om
hun werkzaamheden bij de bestellingen te ondersteunen.
Bedenk vanuit uw standpunt als ober twee user stories van
het format:
ALS ober
WIL IK iets bereiken/wens
ZODAT/OM reden of voordeel
Vijf voorbeelden voor een Definition of Done:
- Volledige testdekking: Alle nieuwe code is uitgebreid getest om ervoor te zorgen dat het correct werkt en geen onbedoelde neveneffecten heeft. Dit omvat unit tests, integratietests en acceptatietests.
- Code review afgerond: Alle code is gereviewd door teamleden om de kwaliteit te waarborgen, te zorgen voor naleving van coding standards en om kennisdeling te bevorderen.
- Documentatie bijgewerkt: Alle relevante documentatie, zoals gebruikershandleidingen of technische documentatie, is bijgewerkt om veranderingen in de code of functionaliteit weer te geven.
- Acceptatiecriteria voldaan: Alle acceptatiecriteria van de user stories zijn vervuld, en de functionaliteit is goedgekeurd door de Product Owner.
- Geen bekende bugs: Het product bevat geen bekende bugs of fouten die de functionaliteit van de software kunnen beïnvloeden.
2 . Twee user stories voor de ober:
ALS ober
WIL IK snel en eenvoudig bestellingen kunnen opnemen
ZODAT ik de efficiëntie van de service kan verhogen en een betere klanttevredenheid kan bieden.
ALS ober
WIL IK real-time toegang hebben tot de keukenstatus en beschikbaarheid van gerechten
ZODAT ik de gasten nauwkeurig kan informeren over de wachttijd en eventuele beperkingen, waardoor de klanttevredenheid wordt verbeterd.
In een scrumproject is het belangrijk om taken en verantwoordelijkheden bij de juiste rol te beleggen. Hieronder ziet u een aantal taken en verantwoordelijkheden die voorkomen in een scrumproject. Geef aan bij welke rol dit binnen scrum thuishoort.
- Steun voor de scrumaanpak binnen de business organiseren.
- Maximaliseren van de bedrijfswaarde van het te maken product.
- Het maken van schattingen.
- De spelregels van scrum bewaken.
- Het team motiveren om volgens scrum te werken.
- Onderhouden van de product backlog.
- Belemmering wegnemen.
- Schrijven van functionele en technische documentatie.
- Inventariseren van stakeholders.
- Invoeren van scrum in de organisatie.
- Continuous integration.
- Bijwerken van de burndown chart.
Hier zijn de taken en verantwoordelijkheden gekoppeld aan de relevante rol binnen Scrum:
- Steun voor de scrumaanpak binnen de business organiseren.
Rol: Scrum Master.
Verklaring: De Scrum Master is verantwoordelijk voor het faciliteren van de implementatie van Scrum in de organisatie en het zorgen voor begrip en steun voor de scrumaanpak. - Maximaliseren van de bedrijfswaarde van het te maken product.
Rol: Product Owner.
Verklaring: De Product Owner is verantwoordelijk voor het maximaliseren van de bedrijfswaarde door te bepalen welke functies en taken prioriteit hebben in de product backlog. - Het maken van schattingen.
Rol: Development Team.
Verklaring: Het Development Team is verantwoordelijk voor het inschatten van de benodigde inspanning om product backlog-items af te ronden tijdens de sprint planning. - De spelregels van scrum bewaken.
Rol: Scrum Master.
Verklaring: De Scrum Master bewaakt de toepassing van de Scrum-regels en zorgt ervoor dat het team zich houdt aan de Scrum-praktijken. - Het team motiveren om volgens scrum te werken.
Rol: Scrum Master.
Verklaring: De Scrum Master ondersteunt en motiveert het team om effectief volgens de Scrum-methodiek te werken. - Onderhouden van de product backlog.
Rol: Product Owner.
Verklaring: De Product Owner is verantwoordelijk voor het onderhouden van de product backlog, inclusief het prioriteren van items en het bijwerken van de beschrijvingen. - Belemmering wegnemen.
Rol: Scrum Master.
Verklaring: De Scrum Master is verantwoordelijk voor het identificeren en wegnemen van belemmeringen die het team kunnen tegenhouden. - Schrijven van functionele en technische documentatie.
Rol: Development Team.
Verklaring: Het Development Team is verantwoordelijk voor het produceren van de benodigde functionele en technische documentatie. - Inventariseren van stakeholders.
Rol: Product Owner.
Verklaring: De Product Owner identificeert en beheert de stakeholders en hun belangen in het product. - Invoeren van scrum in de organisatie.
Rol: Scrum Master.
Verklaring: De Scrum Master is betrokken bij het begeleiden en implementeren van Scrum in de organisatie. - Continuous integration.
Rol: Development Team.
Verklaring: Het Development Team is verantwoordelijk voor het continu integreren van code om ervoor te zorgen dat de software voortdurend van hoge kwaliteit is. - Bijwerken van de burndown chart.
Rol: Scrum Master.
Verklaring: De Scrum Master houdt de burndown chart bij om de voortgang van het team tijdens de sprint te visualiseren en te bewaken.
- Scrum kent geen projectmanagersrol. Hoe worden de taken
die een projectmanager in een traditionele
(waterval)projectorganisatie normaliter heeft, opgepakt in een
scrumproject? - Wat is de rol van de scrum master bij de daily scrum?
- Bij welke events zijn stakeholders actief betrokken?
- Taken van een projectmanager in een Scrumproject:
In Scrum is er geen specifieke rol voor een projectmanager zoals in traditionele watervalprojecten. De verantwoordelijkheden die doorgaans door een projectmanager worden uitgevoerd, worden verdeeld over de verschillende rollen binnen het Scrumframework:
Budgetbeheer en financiële planning: De Product Owner is verantwoordelijk voor het maximaliseren van de waarde van het product, inclusief budgetoverwegingen.
Risicobeheer: Risicobeheer wordt een gedeelde verantwoordelijkheid binnen het Scrumteam, waarbij de Scrum Master en het team samenwerken om mogelijke risico’s te identificeren en aan te pakken.
Resourceplanning: Het Development Team is zelforganiserend en bepaalt de beste manier om taken te verdelen en uit te voeren. Er is geen specifieke rol die vergelijkbaar is met de traditionele resourceplanning van een projectmanager.
Statusrapportage: De Scrum Master faciliteert de voortgangsrapportage tijdens de Sprint Review en de Sprint Retrospective, waarbij het team en de stakeholders de gelegenheid hebben om de voortgang te bespreken.
- Rol van de Scrum Master bij de Daily Scrum:
De Scrum Master heeft een faciliterende rol bij de Daily Scrum. Hun verantwoordelijkheden omvatten:
Zorgen voor dat de Daily Scrum op tijd begint en efficiënt verloopt.
Het team helpen zich te concentreren op de gestelde vragen: wat is sinds de laatste Daily Scrum bereikt, wat zal worden bereikt vóór de volgende en welke obstakels staan in de weg.
Eventuele obstakels identificeren en ervoor zorgen dat ze worden aangepakt.
Fungeren als een coach om het team te helpen bij het verbeteren van de samenwerking en efficiëntie. - Events waarbij stakeholders actief betrokken zijn:
Sprint Review: Dit event vindt plaats aan het einde van elke sprint en stelt stakeholders in staat om de incrementele ontwikkelingen te inspecteren en feedback te geven. De Product Owner presenteert het werk dat is voltooid en het team bespreekt wat er tijdens de sprint is geleerd.
Sprint Retrospective: Hoewel de Sprint Retrospective primair gericht is op het Scrum Team, kunnen stakeholders worden uitgenodigd om feedback te geven over de samenwerking en het proces, waardoor er ruimte is voor continue verbetering.
Het is belangrijk op te merken dat stakeholders niet actief betrokken zijn bij de Daily Scrum, Sprint Planning of de Sprint zelf, tenzij uitdrukkelijk uitgenodigd door het Scrum Team.
Een organisatie wil voortaan haar ontwikkelprojecten volgens de scrumaanpak gaan uitvoeren. Er wordt gestart met een klein project waarbij het om slechts enkele sprints gaat. De gekozen timebox voor de sprints is vier weken. De eerste sprint is bijna ten einde. De volgende dag staat de sprint review op de agenda.
- Welke rol dient de sprint review (demo) te geven?
- Wat is de timebox voor de sprint review uit deze casus?
- Van wie mag feedback verwacht worden? Noem twee rollen.
- Rol van de Sprint Review (demo):
De Sprint Review heeft als doel om de incrementele resultaten van de sprint te demonstreren en feedback te verzamelen. De rol die de Sprint Review moet geven, is voornamelijk die van de Product Owner. De Product Owner presenteert de voltooide product backlog-items en beantwoordt vragen van stakeholders.
- Timebox voor de Sprint Review:
De standaard timebox voor een Sprint Review is vier uur per maand ontwikkelingstijd. In dit geval, waar de sprints vier weken duren, zou de timebox voor de Sprint Review in deze casus ook waarschijnlijk rond de vier uur liggen. Het is echter belangrijk op te merken dat de tijd kan variëren op basis van de omvang van het project, de complexiteit van het werk en de behoeften van het team en stakeholders.
- Feedback van wie mag worden verwacht:
Stakeholders: Dit kunnen mensen zijn die belang hebben bij het product, zoals klanten, eindgebruikers, managers of andere betrokken partijen. Hun feedback is waardevol om ervoor te zorgen dat het ontwikkelde product voldoet aan de verwachtingen en de behoeften van de gebruikers.
Scrum Team: Teamleden kunnen feedback geven over het proces, de samenwerking en eventuele obstakels die ze zijn tegengekomen. Hun inbreng is cruciaal voor continue verbetering binnen het team.
- Wat is het voordeel van een korte timebox voor een sprint ten
opzichte van een lange timebox voor een sprint? - Wat wil het zeggen als in een burn down chart de lijn met
actuele prestaties onder de lijn van het initiële plan ligt? - De linkerkolom in onderstaande tabel bevat een aantal
scrumsteekwoorden, de rechterkolom een aantal
omschrijvingen.Geef aan welk steekwoord bij welke
omschrijving hoort
1, Sprint backlog A. Het eerste event aan het begin van
een sprint.
2, Daily scrum B. Het laatste event: wat kunnen we
verbeteren?
3, Sprint planning C. Wordt gedaan door de product owner.
4, Product backlog D. Voortgangsinformatie over
deeltaken van de sprint
bijgehouden door het
developmentteam.
5, Sprint burndown chart E. Demo en feedback.
6, Release planning F. Het bovenste gedeelte van de
product backlog wordt hierheen
verplaatst.
7, Sprint retrospective G. Bevat items geordend op waarde
voor de business.
8, Sprint review H. Developmentteam praat over
voortgang en invulling van die dag.
- Voordeel van een korte timebox voor een sprint:
Het belangrijkste voordeel van een korte timebox voor een sprint (bijvoorbeeld twee tot vier weken) is dat het de flexibiliteit en het vermogen van het team om snel in te spelen op veranderingen vergroot. Korte sprints bieden frequentere feedbackmogelijkheden en stellen het team in staat om zich aan te passen aan wijzigende vereisten of prioriteiten. - Burn down chart en actuele prestaties onder het initiële plan:
Als de lijn met actuele prestaties onder de lijn van het initiële plan ligt in een burn down chart, betekent dit over het algemeen dat het team sneller voortgang boekt dan oorspronkelijk was gepland. Dit kan wijzen op een efficiënter werkend team, betere inschattingen of zelfs het succesvol overwinnen van uitdagingen die eerder waren voorzien. - Koppeling van scrumsteekwoorden aan omschrijvingen:
1, Sprint backlog: D. Voortgangsinformatie over deeltaken van de sprint bijgehouden door het developmentteam.
2, Daily scrum: H. Developmentteam praat over voortgang en invulling van die dag.
3, Sprint planning: A. Het eerste event aan het begin van een sprint.
4, Product backlog: G. Bevat items geordend op waarde voor de business.
5, Sprint burndown chart: D. Voortgangsinformatie over deeltaken van de sprint bijgehouden door het developmentteam.
6, Release planning: F. Het bovenste gedeelte van de product backlog wordt hierheen verplaatst.
7, Sprint retrospective: B. Het laatste event: wat kunnen we verbeteren?
8, Sprint review: E. Demo en feedback.
Van een scrumproject zijn de volgende gegevens bekend:
- Elke sprint duurt twee weken.
- Het totale aantal story points voor het hele project is geschat
op 480. - Prijs per story point: 90 euro.
- Velocity = 60.
Maak een berekening voor de doorlooptijd in weken en de totale kosten van dit scrumproject.
Om de doorlooptijd en de totale kosten van het Scrumproject te berekenen, kunnen we de volgende stappen volgen:
- Berekening van de doorlooptijd in weken:
De doorlooptijd wordt bepaald door het totale aantal story points (480) te delen door de velocity (60).
Doorlooptijd in weken=Totaal aantal story pointsVelocityDoorlooptijd in weken=VelocityTotaal aantal story points
Doorlooptijd in weken=480 : 60 = 8 weken Doorlooptijd in weken=60480=8weken
De doorlooptijd van het project is 8 weken.
- Berekening van de totale kosten van het Scrumproject:
De totale kosten worden bepaald door het totale aantal story points te vermenigvuldigen met de prijs per story point.
Totale kosten=Totaal aantal story points×Prijs per story pointTotale kosten=Totaal aantal story points×Prijs per story point
Totale kosten=480×90 euro=43.200 euroTotale kosten=480×90euro=43.200euro
De totale kosten van het Scrumproject zijn 43.200 euro.
