Commentaar bij de Scrum Guide, versie november 2017

Kijk hier voor de vorige blogpost.

Na de inleiding, de theorie, de Values en de spelers komen we nu toe aan de Events.

Scrum Guide

Scrum Events

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

Commentaar

Mooi om te lezen: ‘to create regularity’. Dat is ook echt wat ik ervaar in een team. Een vaste cadans. Elke sprint hetzelfde. Doordat er regelmaat zit in het sprintritme en de events ontstaat er de ruimte om binnen die structuur creatief te worden.

Een opmerking die ik regelmatig krijg is: ‘zijn dit niet te veel meetings?’, of ‘sinds we Scrummen vergaderen we de hele tijd’.

Daar zijn over het algemeen twee dingen over te zeggen:

  • Veel organisaties houden de oude meetings in stand en voegen de Scrum events daar aan toe. Dan heb je inderdaad wel heel veel meetings! De Scrum meetings zouden genoeg moeten zijn voor alle mogelijke coördinatie, planning en design. Meer meetings zouden vrijwel niet meer nodig moeten zijn.
  • De meetingtijd in een typische sprint van 2 weken zijn ongeveer:
    • 1-3 uur voor de Sprint Planning
    • 1-3 uur voor de Backlog Refinements
    • 1-2 uur voor de Sprint Review
    • 1-2 uur voor de Retrospective
    • 8-10 kwartiertjes voor de Daily Scrums
    • Totaal dus 6 – 12 uur van de 80 uur, ongeveer 10% dus
  • Een deel van die meetings: Sprint Planning en Backlog Refinement, zou ik ‘echt werk’ willen noemen en zeker geen overhead. In die meetings ben je met requirements analyse en detailed design bezig.
  • De andere meetings zou je, als je dat per sé wilt onder het kopje overhead kunnen plaatsen. Maar dat wil zeker niet zeggen dat het overbodige meetings zijn!

Tijdens de sprint mogen er geen veranderingen gedaan worden aan de Sprint Goal. En dus wel aan de Product Backlog Items (de user stories) en zeker aan de technische taken (als je er voor kiest die te maken).

Veel teams menen dat het in Scrum verboden is om de scope, gedefinieerd als de set van stories, te wijzigen. Maar dat staat hier dus niet!

Ieder event in Scrum is een gelegenheid om inspect en adapt toe te passen. Bij de beschrijvingen van de events wordt genoemd wat er voorwerp is van inspectie.

The Sprint

The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.

Sprints contain and consist of the Sprint Planning, Daily Scrums, the development work, the Sprint Review, and the Sprint Retrospective.

During the Sprint:

  • No changes are made that would endanger the Sprint Goal;
  • Quality goals do not decrease; and,
  • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what is being built may change, complexity may rise, and risk may increase. Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost.

Sprint

De Sprint moet altijd een potentially releasable increment opleveren. De organisatie (de PO) kan kiezen om af en toe niet te releasen, dat is prima. Maar als je na een sprint niet in staat bent om te releasen doe je geen Scrum!

Een sprint heeft een design en een flexibel plan. Dat plan is er altijd wel. Backlog items worden gesplitst in taken. Taken worden toegewezen aan mensen (beter gezegd: opgepakt door mensen). Dat krijgt zijn vorm in de Sprint Backlog. Vrijwel alle teams doen dat zo, volgens mij.

Een design voor het werk kom ik wat minder tegen. Het maken van een design is onderdeel van de Sprint Planning.

Cancelling a Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances. But, due to the short duration of Sprints, cancellation rarely makes sense.

When a Sprint is cancelled, any completed and “Done” Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone regroups in another Sprint Planning to start another Sprint. Sprint cancellations are often traumatic to the Scrum Team, and are very uncommon.

De Sprint afbreken

De discussie over het afbreken van de sprint is een theoretische. Ik heb dat in alle organisaties waar ik gewerkt heb maar 1 keer meegemaakt.

Waar ik wel van schrik is de opmerking dat de PO er voor kan kiezen om sommige items toch nog te accepteren. Ik hoop dat dit een ‘slip of the pen’ is. Als de PO items accepteert dan maak je de PO feitelijk de baas van het team. En zo staat het niet in de beschrijving van de rollen. De PO is lid van het team en dus gelijkwaardig aan de andere teamleden.

Sprint Planning

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the Scrum Team to keep it within the time-box.

Sprint Planning answers the following:

  • What can be delivered in the Increment resulting from the upcoming Sprint?
  • How will the work needed to deliver the Increment be achieved?

Topic One: What can be done this Sprint?

The Development Team works to forecast the functionality that will be developed during the Sprint. The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal. The entire Scrum Team collaborates on understanding the work of the Sprint.

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

During Sprint Planning the Scrum Team also crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Topic Two: how will the chosen work get done?

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.

The Product Owner can help to clarify the selected Product Backlog items and make trade-offs. If the Development Team determines it has too much or too little work, it may renegotiate the selected Product Backlog items with the Product Owner. The Development Team may also invite other people to attend to provide technical or domain advice.

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.

Sprint Planning

Dit event wordt uitgevoerd door het hele Scrum team, dus inclusief Product Owner.

De 8 uur timebox is lang (4 uur voor sprints van 2 weken), veel langer dan veel teams doen. Komt dat doordat de Scrum Guide aanneemt dat je hier design doet, en veel teams dat niet doen? Veel teams maken wel een planning, maar het design ontbreekt vaak.

De Sprint Planning wordt opgesplitst in 2 fasen, topic one en topic two. In deel 1 wordt het WAT voor de Sprint bepaald. Welke items trekken we van de Product Backlog. Hier bepalen we ook gezamenlijk (Scrum Team) de Sprint Goal.

Deze fase heeft veel overlap met de Backlog Refinement. Als je de Refinement goed doet kan je Sprint Planning I sneller uitvoeren.

In deel 2 wordt het HOE bepaald. Hier doen we een detailed design voor de geselecteerde items. Hier is dus met name het Development Team aan zet. Ik vraag aan PO en SM vaak om wat anders te gaan doen maar wel in de buurt te blijven. Als je echt nadenkt over het HOE komen vragen over het WAT snel weer op.

Het design geeft antwoorden op: welke views moeten worden aangepast, welke business logica, welke nieuwe/aangepaste elementen in de database? Uit dit design volgen dan vrijwel vanzelf de technische taken.

Bij veel teams zie ik dat de taken een mini-watervalletje zijn: design, programming, testing. Dat vind ik geen handige keuze. Je dwingt jezelf dan in een waterval waar deze fases na elkaar moeten worden uitgevoerd.

Als je de taken meer technisch insteekt: view, logica, database, dan kunnen diverse mensen parallel aan het backlog item werken. Je maakt dan swarming mogelijk.

De Scrum Guide geeft expliciet aan dat je hier niet per se compleet hoeft te zijn voor alle items voor de Sprint. Een eerste Sprint Planning II voor de eerste 3 dagen is prima. Je kan dan na een paar dagen de rest oppakken. Doe het werk op het Last Responsible Moment!

Een nieuw inzicht voor mij was dat je aan het einde van Sprint Planning II moet uitleggen aan PO/SM hoe je het werk gaat aanpakken. Dat doe ik eigenlijk nooit met mijn teams. Maar eens uitproberen binnenkort.

Deel 2 zou deels ook in de Backlog Refinement uitgevoerd kunnen worden. Maar daar zitten twee nadelen aan.

  • Je bent in de huidige sprint al veel werk voor de volgende sprint aan het doen, wat ten koste gaat van de focus
  • Er is het risico van voortschrijdend inzicht bij de PO over de prioriteiten. Als je design hebt gedaan op items die niet zo belangrijk meer zijn is dat pure waste.

Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.

Sprint Goal

Het doel van de Sprint Goal is zorgen voor coherentie zodat je gaat samenwerken. Een gezamenlijke Sprint Goal leidt tot veel meer swarming dan een zooitje losse Backlog Items.

De goal helpt bij het begrijpen van de WAAROM achter de geselecteerde items. Een sprint goal als “we bouwen deze 6 items” is dus geen goede goal. Een betere optie is: “we bouwen een MVP voor de Rapportage-module” is veel beter.

Het Development Team (dus zonder PO en SM) bepaalt hoeveel werk we oppakken!

Daily Scrum

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.

The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within the 15-minute time-box.

The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.

Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. This is a key inspect and adapt meeting.

Daily Scrum

Het doel van de Daily Scrum is het maken van een planning voor de komende 24 uur. Het is dus geen statusmeeting maar een planningsmeeting.

Ik kijk zelf ook graag een beetje verder vooruit. Zeker in de tweede week van een sprint vraag ik in de Daily Scrum graag: “ziet het er naar uit dat we de sprint goal gaan halen?”

De veelgebruikte methode met een rondje langs de teamleden met de 3 vragen: “wat heb je gedaan, wat ga je doen, wat blokkeert je?” is maar een suggestie voor hoe je de meeting kan aanpakken.

Zelf werk ik liever niet met een rondje langs de teamleden maar volg ik het Scrumboard / de Sprint Backlog. Als het goed is is dat bord van boven naar beneden gesorteerd op prioriteit. We beginnen dan met het bovenste item dat nog niet Done is. Wie heeft daar gisteren aan gewerkt? Wie gaat er vandaag aan werken? Wat houdt ons tegen om dit item vandaag af te maken?

Met deze aanpak stimuleer je veel meer swarming en zorg je ervoor dat de bovenste items in ieder geval af komen.

Als iedereen alleen maar status rapporteert: “ik heb vandaag aan item 3451 gewerkt en krijg die vanmiddag wel af”, dan kan je de Daily Scrum gemakkelijk in 3 minuten af krijgen. Maar ik vind dat dan een slechte meeting. Er is geen interactie, er is geen planning voor de komende 24 uur, er is geen voortschrijdend design op basis van nieuwe inzichten.

De meeting mag best behoorlijk inhoudelijk en technisch worden. Het verbaast mij vaak hoe veel technische discussie je kunt hebben in 15 minuten.

Uiteraard moeten te lange discussies worden afgekapt. Na de meeting is er vaan een zogenaamde Afterparty waar subgroepjes van het team verder gaan in een discussie die in de Daily Scrum is gestart.

De Daily Scrum is een interne meeting, maar anderen mogen wel aanwezig zijn zonder te verstoren. De eerste Scrum Guide had hier nog het verhaaltje over de Chicken en de Pig. Dat concept staat nog steeds in de Scrum Guide hoewel het verhaaltje is verdwenen.

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

This is at most a four-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendees understand its purpose. The Scrum Master teaches everyone involved to keep it within the time-box.

The Sprint Review includes the following elements:

  • Attendees include the Scrum Team and key stakeholders invited by the Product Owner;
  • The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”;
  • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved;
  • The Development Team demonstrates the work that it has “Done” and answers questions about the Increment;
  • The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed);
  • The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning;
  • Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next; and,
  • Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Sprint Review

Een Sprint Review is niet alleen maar een Demo. Zo wordt de meeting vaak genoemd, maar dat is onjuist en onvolledig.

Je doet hier twee dingen:

  • Inspect the increment: dat is het demo deel
  • Adapt the product backlog

Als je het Increment laat inspecteren door de juiste mensen: stakeholders, gebruikers, etc. dan zullen zij daar wel een mening over hebben. Het product is misschien een andere kant op gegaan dan zij willen. Of ze zien iets moois in het product en vragen dan “als dit kan, kan dan dat ook?”. Dat soort opmerkingen moet je natuurlijk we serieus nemen, en ze dus een plek geven in de Product Backlog.

Als ik zelf als Scrum Master een Sprint Review faciliteer dan ga ik naast een flip-over staan en schrijf alle (nuttige) opmerkingen van de stakeholders op. Alleen dat is al prettig voor ze. Ze voelen zich dan in ieder geval gehoord en serieus genomen. Aan het einde van de meeting loop ik met de groep door de opmerkingen heen. Met name de Product Owner is hier aan zet. Wat gaan we doen met de opmerkingen? Negeren? Meteen oppakken? Later oppakken? Ik schrijf dit erbij in een andere kleur en geef dan het flipover-vel aan de PO, zodat hij de opmerkingen in de Product Backlog kan verwerken.

Wat ik niet vaak doe, maar wel wil gaan oppakken, is de opmerking: The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved”.

Ook hier is het nuttig om transparantie te geven. Hoe is de sprint gegaan? Waarom is niet alles af? Wat viel er tegen? Of juist andersom, waarom ging het superlekker en hebben we iets extra’s opgepakt?

De Scrum Guide schrijft hier een beetje voor dat de demo zelf door de developers moet worden gedaan. Ik varieer zelf nog wel met wie er presenteert. Iedere rol heeft zo zijn eigen voor- en nadelen:

  • Developers
    • Voordeel: ze weten echt in detail wat er is gebouwd/getest en kunnen dat goed beschrijven. En het presenteren ervan kan met trots worden gedaan.
    • Nadeel: het gaat soms teveel in de nerdy details en de vertaling naar wat een gebruiker ermee kan, wat de business value is komt vaak niet goed naar voren
  • Product Owner
    • Voordeel: kan in de regel goed de vertaling maken tussen de techniek (wat/hoe is er gebouwd) en de business value ervan
    • Nadeel: de PO gaat met de eer strijken terwijl de development teamleden het werk hebben gedaan.
  • Stakeholders, deze variant kwam ik bij een van mijn klanten tegen. De ‘requestor’ vanuit de business die om dit item heeft gevraagd doet zelf de demo
    • Voordeel: de stakeholder is heel sterk betrokken, ook al tijdens de sprint, want om een mooie demo te geven moet je wel al een beetje oefenen en spelen met het product
    • Nadeel: ik zie er geen, maar deze variant kan je alleen maar toepassen als er ook inderdaad een duidelijke requestor is voor een nieuwe feature

Wat me verder wel opvalt in de beschrijving is dat er open gesproken wordt over een review van timeline, budget, etc. Er wordt nogal eens gezegd dat je in Scrum niet met timelines/deadlines kan werken. Daar ben ik het niet mee eens (dat is misschien nog wel eens een eigen blog waard) en de Scrum Guide lijkt me hier gelijk te geven.

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning. This is at most a three-hour meeting for one-month Sprints. For shorter Sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose.

The Scrum Master ensures that the meeting is positive and productive. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process.

The purpose of the Sprint Retrospective is to:

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements; and,
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

Retro

De retro is mijn favoriete Scrum Event (hoewel de Sprint Review een goede tweede is). Hier heb je als Scrum Master echt de kans het verschil te maken bij een team.

Ik varieer graag met de werkvormen. Elke sprint dezelfde manier van werken leidt niet tot maximale creativiteit. Mijn belangrijkste inspiratiebron in de Retromat. Deze site bevat creatieve werkvormen voor elke stap in de retro: Open, Gather Data, Generate Insight, Decide what to Do, Close.

Hierin vind ik de ‘Decide what to do’ stap de belangrijkste. Ik heb het liefst maar 1 verbeterpunt als output van de retro. Daarmee is de kans op implementeren het grootst.

Om te stimuleren dat we echt iets doen met de retro’s voeg ik altijd nog wel een stap toe aan de 5 stappen: als eerste vraag ik naar de vorige retro. Wat hebben we daar als verbetering afgesproken? Is er iets van gekomen om dit te implementeren in de afgelopen sprint? Als het antwoord ‘nee’ is doe ik geen nieuwe retro, maar een meta-retro. Hoe kan het toch komen dat we een verbetering kiezen als allerbelangrijkste voor ons team en die dan verder volledig negeren?

In de laatste versie van de Scrum guide is het uitvoeren van verbeteringen ook sterker aangezet. Het is nu verplicht om minimaal 1 verbeterpunt uit de retro toe te voegen aan de Sprint Backlog, zodat deze tijdens de volgende sprint ook echt aandacht krijgt.

Aanpassingen die we doen kunnen op allerlei terreinen liggen. De Scrum guide suggereert dat we de werkprocessen of de Definition of Done aanpassen.

Klik hier om uw eigen tekst toe te voegen