Scrum Guidelines:

Timebox: 8 hours for 1 month sprint

Sprint Planning Flow: DoD + Dev Team (capacity & velocity) + Product Backlog + Retrospective Commitments -> Sprint Goal + Forecast (plan on how) + Sprint Backlog

Sprint Goal: An objective to be met in the sprint

• Capacity check: Wie is er af en aanwezig (let op gepland medisch verlof, trainingen en vrij)
• Beheer check: Wat heeft er gespeeld op beheer gebied (incidenten, requests, daily check)
  • Welke incidenten staan nu langer open dan 2 weken en moeten dus naar de sprint?
• Sprint backlog samenstellen
  • Wat is het self improvement item deze sprint.
  • Let op templates
  • Let op Lange Termijn Planning
  • Let op UserStories die specifiek gepland zijn voor deze periode
• Sprint Goal: Wat is het belangrijkste doel van deze sprint en wat is de urgentie
  • Bij een hoge urgentie hebben we goede ervaring opgedaan met het opstellen van een MDT oplosteam (incl leverancier/eerste&tweede lijn teams) en een daily standup te houden
• Verslag in Confluence

Scrum Guidelines:

Timebox: 3 hours for 1 month sprint

Scrum team inspects how the last sprint went:

    People & Relationships
    Process
    Environment (tools)
    Quality

Scrum team selects top actionable improvements to implement in next sprint

• HPI Team & PO
• Wat is er goed en niet goed gegaan
• Hoe is de self improvement gegaan
• Opstellen actiepunten in backlog
• Verslag in Confluence

Scrum Guidelines

Timebox: 4 hours for 1 month sprint

Review:

    Vision of the product
    Share sprint Goal
    Product Backlog (bijwerken waar nodig) + projects to be discussed
    Increment
    Current Business Conditions - Market change, review timeline & budget
    Get stakeholder feedback

• Sprint backlog afsluiten
• Product backlog bijwerken aan de hand van bevindingen en resultaten
• Wat heb je gedaan aan innovatie?
• Demo interessante items
• Verslag in Confluence

Scrum Guidelines

Timebox: 10% of the capacity

Product backlog is continuously refined to increase understanding, granularity and transparency

Everything is allowed on product backlog: Userstories, Testing, bugs, self improvements, etc.

User stories zijn niet de enige onderdelen in de product backlog. Officieel heten alle items op de product backlog namelijk (je raadt het al): “product backlog items” (PBI). Het verschil zit hem in de formulering van het item wat bepaalt of we het hebben over een story of een product backlog item.

Hele grote stories worden soms “epics” genoemd. Deze epics bevatten stories gegroepeerd naar de volgorde waarop je het systeem zou uitleggen aan een onbekende.

Een user story formuleren wij aan de hand van de volgende template:

Als <rol> wil ik <wens> zodat ik <benefit>

Voorbeeld: Als bezoeker wil ik altijd het hoofdmenu in beeld hebben zodat ik gemakkelijk kan navigeren door de site.

User stories moeten zo duidelijk geformuleerd worden dat ze ruimte overlaten voor interpretatie van de uitvoering, maar compact genoeg zijn te kunnen overzien en te begrijpen. Denk aan INVEST:

N.B. er zijn altijd elementen of functionaliteiten die zo duidelijk zijn, dat het onzinnig is om de template “Als wil ik zodat ik ” te gebruiken. Doe dat dus ook niet. Meestal gaat het hier om vrij technische onderdelen. Denk bijvoorbeeld aan: de OTAP inrichting, of de basis HTML-template.

• Controleer welke items moeten worden refined aan de hand van het label “refinement”
• Verhelder een item aan de hand van planning poker en zorg voor een inschatting van het aantal storypoints
• Werk het JIRA item bij.
  • Bij een vaste datum / sprint zorg dat het item in de titel de datum heeft en dat ie eventueel alvast in de goede sprint staat.
  • Indien duidelijk is wie het moet uitvoeren geef dan ook een assignee
  • Maak duidelijk of dit als change via het changeproces moet lopen + inschatting small/medium/large
  • Maak duidelijk op welke projectcode geschreven moet worden