Commentaar bij de Scrum Guide, versie november 2017

Kijk hier voor de vorige blogpost.

Na de inleiding, de theorie, de Value, de spelers en de Events komen als laatste de Artifacts aan de beurt: Product Backlog, Sprint Backlog, Increment en Definition of Done.

Scrum Guide

Scrum Artifacts

Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.

Commentaar

Artifacts

De artifacts (artefacts als je meer van Brits Engels houdt) zijn ontworpen om je de gelegenheid te geven om Inspect and Adapt toe te passen. Ze maken van alles transparant.

Tenminste, als je ze ook zichtbaar maakt voor de juiste mensen. Een Jira backlog die niet leesbaar is voor de stakeholders helpt dan niet echt.

Product Backlog

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

A Product Backlog is never complete. The earliest development of it lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate, and value. Product Backlog items often include test descriptions that will prove its completeness when “Done”.

As a product is used and gains value, and the marketplace provides feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a living artifact. Changes in business requirements, market conditions, or technology may cause changes in the Product Backlog.

Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be “Done” within the Sprint time-box. Product Backlog items that can be “Done” by the Development Team within one Sprint are deemed “Ready” for selection in a Sprint Planning. Product Backlog items usually acquire this degree of transparency through the above described refining activities.

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

Monitoring Progress Toward Goals

At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.

Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.

Product Backlog

De enige lijst met alles dat we weten dat gedaan moet worden aan het product.

Wat zetten we er allemaal op? De gewenste features in ieder geval. Persoonlijk houd ik die lijst graag overzichtelijk en houdt ik de backlog op ongeveer 50 items.

Naast features zou je er ook bugs op kunnen zetten. Er zijn diverse argumenten voor en tegen. Mike Cohn heeft dat wel goed beschreven.

De items op de Product Backlog heten in Scrum gewoon Product Backlog Items, of PBI’s. Veel organisaties gebruiken de term User Stories voor die items. Een User Story is een nuttig format om de items te beschrijven, maar belangrijker, een stimulans om items vooral met elkaar te bespreken, dat is waardevoller dan beschrijven.

PBI’s hebben een beschrijving, een volgorde, een schatting, een waarde en meestal ook een testbeschrijving.

Schattingen voor omvang (hoeveelheid werk) worden vaak in Story Points aangegeven, maar dat is geen eis in Scrum. Het concept komt uit Extreme Programming. Elke manier van schatten waar een team goed mee uit de voeten kan is OK.

De waarde van een item zou je ook in een soort Story Points kunnen uitdrukken. Je zou daarvoor de term Value Points kunnen gebruiken.

Als je met meerdere Scrum teams aan 1 product werkt dan moet je met 1 Product Backlog werken. Logisch, het is een Product backlog, geen Team backlog.

De vraag is dan wel: wat is een product? Je zou elke component van je product als product kunnen definiëren. Maar dat is niet de bedoeling. In de LeSS cursus leerde ik een heel nuttige definitie, een Product is iets dat een klant/gebruiker als product herkent.

Hier wordt de Backlog Refinement beschreven. Ik ervaar dit zelf toch vooral als een event. Scrum ziet dat niet zo. Vermoedelijk omdat het niet, net als andere events, een duidelijk plaats in het proces heeft. De sprint planning zit aan het begin, de review aan het einde. Maar er zijn heel veel manieren om de Refinement uit te voeren.

De termen Done en Ready worden hier beiden beschreven. Een item is Ready als je er redelijkerwijs op kan vertrouwen dat dit in 1 sprint gebouwd kan worden, naar Done toe.

Done heeft ook een eigen formele definitie in een eigen artifact. Voor Ready is er geen formele definitie artifact, hoewel veel teams die wel gebruiken. Ik ben er zelf erg terughoudend mee en maak pas een Definition of Ready als ik het gevoel heb dat ik daar echt een probleem mee oplos. Als er echt vaak gedoe is dat het team met te onduidelijk Items moet werken dan kan de DoR handig zijn. Maar meestal is het beter uitvoeren van de Backlog Refinement, meer gewoon praten met elkaar, een betere oplossing van dat probleem.

In de Refinement doe je ook je schattingen. Sommige teams doen dat pas tijdens de Sprint Planning, maar dat is wat mij betreft te laat. Als je de schattingen weet, en je kent de velocity van je team kan je gemakkelijk Sprint Planning I uitvoeren. Met een velocity van 20 kan je dan bijvoorbeeld items van 8, 6, 4 en 2 punten groot oppakken.

DePO mag het team beïnvloeden over de schattingen, maar het Development Team bepaalt uiteindelijk zelf wat de schatting is. Als de PO bijvoorbeeld verwacht dat een item maar 2 punten groot is en het team schat 20 punten in, dan is het mogelijk dat het team een veel ruimere interpretatie heeft van het item dan de PO. Het is dan zeker nuttig het gesprek aan te gaan. Het kan natuurlijk ook zo zijn dat het gewoon veel meer werk is dan de PO denkt. Op dat moment zou de PO het item ook kunnen terugtrekken. De kosten wegen dan mogelijk niet op tegen de baten.

Er wordt vaak gezegd dat je in Scrum niet met planningen of deadlines kan werken. De tekst in de Scrum Guide is anders. Er wordt gemonitord ten opzichte van de doelen. Je kan een doel hebben om een grote feature over 4 sprints af te hebben. Tijdens elke sprint kijk je dan of je dat nog lijkt te halen. De PO houdt minimaal elke sprint bij hoe het er voor staat.

De Product Backlog heeft in Scrum de taak van het projectplan overgenomen. Als je alle items hebt ingeschat, en je kent je velocity, dan kan je gewoon goed vooruitkijken en voorspellingen maken. Wel geldt uiteraard dat voorspellingen altijd spannend zijn. Als de backlog verandert, of de velocity, dan veranderen ook de voorspellingen.

Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

The Sprint Backlog makes visible all the work that the Development Team identifies as necessary to meet the Sprint Goal. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. As work is performed or completed, the estimated remaining work is updated. When elements of the plan are deemed unnecessary, they are removed. Only the Development Team can change its Sprint Backlog during a Sprint. The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, and it belongs solely to the Development Team.

Monitoring Sprint Progress

At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal. By tracking the remaining work throughout the Sprint, the Development Team can manage its progress.

Sprint Backlog

De Sprint Backlog is ook een plan. Maar dan voor alleen 1 sprint.

Mijn voorkeur om dit aan te pakken is als volgt. Tijdens Sprint Planning II wordt detailed design gedaan. We schetsen op flipovers hoe we de backlog items gaan oplossen: een scherm aanpassen, nieuwe tabel in de database, andere logica om gegevens te verwerken in een bestaande class, of nieuwe classes. Als dat design gedaan is (met het hele team) is het heel gemakkelijk om daar technische taken van te maken (maak nieuw scherm, pas class X aan, etc.).

Ik mik hier altijd op taken die ongeveer 4 uur werk zijn voor 1 persoon.

Dat lijstje met taken is je Sprint Backlog. Dat lijstje is dynamisch. Als je aan het bouwen/testen bent krijg je altijd weer nieuwe ideeën, het kan soms slimmer, of wat je gepland had kan niet. En dan pas je dus je Sprint Backlog gewoon aan. Taken eraf, taken erbij, taken veranderen. Puur een teambeslissing. De PO is er niet of nauwelijks bij betrokken.

In LeSS wordt sterk geadviseerd om verschillende tools te gebruiken voor de Product en de Sprint Backlog. Wat ze hebben een heel andere doelgroep (resp. PO en Development team) en een heel andere dynamiek.

Met co-located teams is er eigenlijk maar 1 geschikte vorm voor een Sprint Backlog: een fysiek bord met post-its.

Een tool als Jira is geschikter voor de Product Backlog, maar meestal is plain Excel nog beter.

Om continuous improvement te behalen is het sinds de laatste versie van de Scrum Guide verplicht om minimaal 1 item uit de Retro op de Sprint Backlog te zetten.

Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done”. An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.

Increment

Het increment is de som van alle done PBI’s van deze en de vorige sprints.

Het increment moet bruikbaar/releasebaar zijn aan het einde van de sprint. Onafhankelijk van het feit of de PO wil releasen of niet.

Artifact Transparency

Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. To the extent that transparency is complete, these decisions have a sound basis. To the extent that the artifacts are incompletely transparent, these decisions can be flawed, value may diminish and risk may increase.

The Scrum Master must work with the Product Owner, Development Team, and other involved parties to understand if the artifacts are completely transparent. There are practices for coping with incomplete transparency; the Scrum Master must help everyone apply the most appropriate practices in the absence of complete transparency. A Scrum Master can detect incomplete transparency by inspecting the artifacts, sensing patterns, listening closely to what is being said, and detecting differences between expected and real results.

The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.

Artifact transparency

Inspect/adapt heeft alleen zin als je je op feiten baseert. Hoe meer je niet transparant maakt, hoe slechter inspect/adapt werkt.

Alle relevante personen moeten de artifacts dus ten allen tijde kunnen inzien: de Product Backlog, Sprint Backlog, Increment en Definition of Done.

Het is een taak voor de SM om deze transparantie steeds beter te maken.

Definition of “Done”

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

The same definition guides the Development Team in knowing how many Product Backlog items it can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done”.

Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. If the definition of “Done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum.

If “Done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “Done” appropriate for the product. If there are multiple Scrum Teams working on the system or product release, the Development Teams on all the Scrum Teams must mutually define the definition of “Done”.

Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality. New definitions, as used, may uncover work to be done in previously “Done” increments. Any one product or system should have a definition of “Done” that is a standard for any work done on it.

Definition of Done

In sommige organisaties wordt er op organisatieniveau een DoD gemaakt. Alle teams moeten zich hier dan minimaal aan conformeren. Een strengere DoD mag altijd, maar minder mag niet.

Als er geen DoD aangeboden wordt vanuit de organisatie maakt het Development team deze zelf.

De DoD kan elke Sprint weer aangepast worden. Met name de Retrospective levert daarvoor de input.

Uiteindelijk geldt wat mij betreft dat de enige correct DoD er een is waarbij items snel naar Productie gaan. Tot die tijd is het Scrum-team niet echt mature.

In LeSS wordt gesproken van de Definition of Done en de Definition of Undone. In die laatste beschrijf je alles wat je nog moet doen nadat je Done bent maar voordat je echt in Productie bent. Je kan een speciale Undone afdeling maken die dat werk uitvoert, bijvoorbeeld langlopende performance tests uitvoeren of security tests waarvoor de teams de skills niet hebben. Maar dat Undone department mag dat nooit te lang blijven uitvoeren. Het doel moet zijn om die skills naar de teams zelf te brengen of te automatiseren.

Zo, hè hè, Done met deze serie blogs. Dat was wat meer weer dan ik bedacht had toen ik eraan begon. Maar het is erg nuttig voor me geweest om de Scrum Guide weer eens te spellen. Hopelijk heb ik er ook nog iemand mee geholpen.