Backlog refinement – hoe zit dat nou precies?

De backlog refinement is een activiteit in Scrum waar veel onduidelijkheid over is. De scrum guide behandelt het niet als een meeting zoals de sprint planning of de retrospective. Die meetings hebben een duidelijke plaats aan het begin of het einde van de sprint. Maar de backlog refinement (verder: refinement) heeft niet 1 duidelijke plaats in de sprint, en wordt dus terecht wat anders behandeld.

De letterlijke tekst in de scrum guide is als volgt:

Product Backlog verfijning (“Refinement”) is het toevoegen van detail, schattingen en volgorde aan de items op de Product Backlog. Dit is een doorlopend proces waarbij de Product Owner en het Ontwikkelteam samenwerken aan de details van de Product Backlog items. Gedurende Product Backlog verfijning worden items beoordeeld en bijgewerkt. Refinement neemt gewoonlijk niet meer dan 10% van de capaciteit van het Ontwikkelteam in beslag. Echter, Product Backlog Items kunnen op elk moment worden bijgewerkt door de Product Owner of naar de Product Owner’s eigen beoordeling.

Het doel van de backlog refinement is dus dat het team en de product owner gezamenlijk werken aan een goede backlog. Om dit werk wat duidelijker te maken volg ik de tijdlijn van een nieuw idee naar werkende software.

Een nieuw idee start bij een stakeholder. Misschien bij een klant die met een idee of een klacht komt, misschien bij iemand van de business die een slim idee heeft of misschien bij een developer die vanuit de techniek een suggestie heeft. Elk item dat opgepakt gaat worden door het team moet als een item op de product backlog komen en de product owner beheert deze backlog. Dus de stakeholder die een idee heeft moet in gesprek gaan met de product owner. Dit gesprek is de eerste backlog refinement die plaatsvindt. Misschien zijn hier alleen maar de product owner en stakeholder met elkaar in gesprek. Uit dit gesprek ontstaat een helderder beeld van het idee en kan dit op de product backlog geplaatst worden. Je zou dit business refinement kunnen noemen.

Vervolgens moet dit idee met het development team besproken worden. Zij moeten helder krijgen wat er ontwikkeld moet worden en zij moeten er een inschatting van maken zodat de product owner een geïnformeerde beslissing kan nemen of zij dit item wel of niet wil laten ontwikkelen. Deze refinement kan met het gehele team gedaan worden, maar het is ook mogelijk om een eerste refinement te doen met een deel van het team. (sommigen noemen dit een pre-refinement, of prefinement). En het is zeker mogelijk om de stakeholder die met dit idee gekomen is ook uit te nodigen voor deze prefinement. Niemand kan dit idee immers beter uitleggen dan de indiener zelf.

Als een idee al behoorlijk duidelijk is en de product owner er redelijk zeker van is dat dit idee snel ontwikkeld gaat worden is een refinement met het gehele team verstandig. Als het idee nog redelijk vaag is en nog even kan wachten kan het verstandig zijn om niet het gehele team in deze discussie te betrekken. Waarom de tijd van iedereen inzetten op een idee dat de discussie misschien niet overleeft? Na de prefinement moet in ieder geval nog een ‘echte’ refinement volgen, zodat het gehele team het item begrijpt en betrokken is bij de schatting. Als het nodig is kunnen meerdere refinement sessies gehouden worden voor een item, totdat deze helemaal helder is. Items worden tijdens de refinement geschat. Als items door de refinement discussies helder geworden zijn kunnen ze ingeschat worden en zijn ze klaar om in een volgende sprint opgepakt te worden.

Het oppakken in een sprint vindt plaats in de sprint planning meeting. Als voorafgaand aan deze meeting een goede refinement plaats heeft gevonden is het eerste deel van deze meeting heel eenvoudig. We kennen onze velocity, bijvoorbeeld 30 punten, en selecteren items ter waarde van 30 punten. De product owner heeft hier een belangrijke stem in. Zij bepaalt welke items bovenaan de backlog staan en suggereert een sprint goal waar stories bij gekozen kunnen worden. Maar ook developers hebben hier een stem in. Soms is er winst te behalen door soortgelijke items als groep op te pakken. En er kan een technische reden zijn om items in een bepaalde volgorde op te pakken. Naast het kiezen van de stories blijft dan het tweede deel over van de sprint planning, waar technische taken bedacht worden om de stories te realiseren. Dat onderwerp laat ik in deze blog verder liggen.

Het zou kunnen dat tijdens de sprint er toch nog kleine onduidelijkheden naar boven komen. Deze kunnen vaak in afstemming met de product owner nog worden verhelderd. Je zou dit de after-refinement kunnen noemen.

Advertisement

Vuistregels voor User Stories en Taken

Ik zie veel verschillen in hoe teams met user stories en met taken omgaan.
Dit is de manier waarop ik er het liefste mee omga.

Een User Story is een redelijk grote brok werk die waarde oplevert voor een of meer stakeholders.
Meestal heb ik ongeveer 6-10 stories in een sprint. Dat betekent dus dat in een sprint van 2 weken een story ongeveer 1 teamdag kost. In doorlooptijd is het meestal meer. Een story heeft vaak een doorlooptijd van een dag of 4.
Een story wordt vrijwel altijd door meer dan 1 persoon gebouwd. Die personen zijn meestal 1 of meer ontwikkelaars en meestal 1 tester. Een kleine story wordt door 1 ontwikkelaar gebouwd. Bij een grotere story zijn meer ontwikkelaars betrokken, soms zelfs het hele team.
Een story wordt ingeschat in story points.

Een (technische) taak is een brokje werk dat deel uitmaakt van een story. Wat mij betreft is de ideale grootte van een taak gemiddeld 4 uur met een minimum van 1 uur en een maximum van 8.
Een taak wordt altijd maar door 1 persoon tegelijk opgepakt (behalve bij pair programming). Ik geef taken bij voorkeur geen echte schatting meer. We schatten taken uiteraard niet in story points, want het zijn story points geen taskpoints. Door te zorgen dat de taken gemiddeld 4 uur groot zijn heeft het geen zin meer om ze nog een schatting mee te geven (deze taak is 1 uur, die 4 en die taak is 7 uur). Doordat er redelijk veel taken in een sprint zitten middelt dit gemakkelijk uit.

Samengevat: Story
– schatten in story points
– werk voor meerdere mensen

Task
– geen individuele schatting, maar gemiddeld 4 uur
– werk voor 1 persoon alleen

Story points aanpassen voor een nieuwe developer?

Het team dat ik op dit moment coach is nu sinds 3 sprints aan het schatten in story points. We hebben op basis van de afgeronde stories van de laatste sprints een story point liniaal gemaakt zodat we een goede referentie hebben. Nieuwe stories houden we gewoon tegen deze liniaal aan. Lijkt het op de andere vijfjes? Dan is het ook een vijf.
Recent kregen we er een nieuw teamlid bij. Een ervaren ontwikkelaar, maar nieuw in onze team en dus niet bekend met ons business domein en met de opzet van onze code. Hij zal er voorlopig wat langer over doen dan de anderen om een story af te ronden.
Hoe gaan we hiermee om met de schattingen? Moet je de stories die hij gaat doen meer punten geven?
NEE, dat gaan we zeker niet doen. Dat helpt het hele mechanisme om zeep.
Ten eerste kan het al niet. We weten vooraf niet precies wie aan welke story gaat werken. We werken met zoveel mensen als zinvol mogelijk is aan de eerste story en starten dan pas met story 2. Wie wat gaat doen wordt pas heel kort van te voren duidelijk.
Maar ten tweede zou zo’n aanpassing aan een nieuwe (of aan een junior) programmeur het hele idee van story points om zeep helpen. De story points geven aan hoe groot een story is voor dit team. Het schatten van stories blijft gedaan worden tegen onze liniaal. Als deze story lijkt op de vijven van onze liniaal dan krijgt ‘ie 5 punten.
Als er een nieuw teamlid bij komt verandert het team, en daarmee verandert de velocity. Een nieuwe ontwikkelaar haalt meestal eerst de velocity omlaag. Hijzelf levert nog niet veel output op en met al z’n vragen houdt hij de ervaren teamleden van het werk. Hopelijk stijgt de velocity later wel, als hij meer zelfstandig z’n taken gaat oppakken.
Daarmee is de velocity een eerlijke maat van de output van ons team.

Start van Valueminds

Vanaf 1 januari 2017 start ik, in samenwerking met Testpeople, het bedrijf Valueminds. Vanuit Valueminds willen we onze klanten waarde leveren door ervaren agile coaches, scrum masters en product owners te detacheren. Valueminds levert mensen die gepokt en gemazeld zijn in hun vak. Ze kennen niet een agile trucje, ze hebben agile denken diep in hun minds en hun gevoel zitten. Maar ze kennen niet alleen agile. Door hun uitgebreide bedrijfservaring kunnen ze ook gewoon met gezond verstand meedenken en meewerken. Ze weten hoe ze een team moeten bouwen, hoe ze mensen kunnen verbinden, wanneer het nodig is om zelf in actie te komen en wanneer het verstandig is om de zelf-organisatie de ruimte te geven.

Ik werk al een aantal jaar zo af en toe samen met Testpeople en ben altijd erg enthousiast over dit bedrijf. De medewerkers staan er absoluut op nummer 1. Een mooi voorbeeld daarvan is hoe deze samenwerking ontstond. Een aantal testers uit Testpeople gaf aan wel interesse te hebben om een agile rol op zich te nemen. In plaats van de reactie: “dan moet je maar eens een nieuwe werkgever zoeken” kwam er de reactie: “dan gaan we maar eens kijken of we daar iets voor kunnen regelen”. En zo werd bekeken of er geen nieuw bedrijf gestart kon worden en werd ik gevonden als trekker voor dat bedrijf.
Naast een bedrijf met de medewerkers op nummer 1, is er ook veel aandacht voor de maatschappij en worden er op allerlei manieren diverse goede doelen in Nederland en daarbuiten ondersteund.
Gevolg is dat dit een zeer gezond bedrijf is met testers waar hun klanten erg enthousiast over zijn en een uitzonderlijk laag personeelsverloop.
We hopen dat het kleine zusje een flink stuk van dit DNA zal erven.

De bedoeling is dat Valueminds in de komende jaren groeit naar ongeveer 25 medewerkers, net als Testpeople op dit moment.

Interesse om eens kennis te maken om jouw bedrijf meer agile te maken? Neem dan contact op met André Heijstek, andre.heijstek@valueminds.nl, 0648476451
Vind je jezelf in bovenstaand profiel passen? Neem maar contact op.

Groet, André

Splitting up a Scrum team

The Scrum-guide states, correctly in my opinion, that a Scrum team should be 3-9 people in size.

The team that I am coaching at the moment grew to 11 persons, so it was about time to split. The reason to split was not the Scrum-guide, we’re not that scrumdamentalistic. But our size got in the way:

• first of all very practically, the physical space became too small for us
• we also noticed that our meetings took longer and longer. In a large team everyone needs to speak up at some time and that simply makes the meetings longer
• and most importantly, many people in a room created too much unrest. Team members interact and all others listen in (with half an ear, as we say in Dutch), system user come in with questions, stakeholders with ideas, and we lost the quietness to work focused too often

After splitting up, we noticed a major difference in this last point. Especially in the smaller subteam (4 persons) that moved away to a smaller, separate room.

We thought carefully about how to split the team. We identified 3 possible splitting seams:

1. development versus maintenance, in other words, building new features versus maintaining existing features
2. functional support versus development; the team had 5 developers, 2 testers, 2 functioneel supports, 1 scrum master/tester and one product owner. In this option the functional supporters and PO would form a ‘ready-team’, separate from the development team
3. Splitting along technical or functional seams in the system

Our steering committee expressed preference for option 1. The team is slowed down in developing new stuff because they often have to fix bugs or to do small functional upgrades to existing stuff to make the system easier to use. New development does not get the focus to really make progress.

The disadvantage of this option however is that it calls for a perverse mentality. The new-development team is ‘allowed to’ deliver low quality software because the maintenance team is there to fix it later. Of course, nobody will explicitly admit this behaviour, but the unconscious tendency is built into the team setup. An approach where ‘the polluter pays’, where the person who creates the bug should fix them, had our preference.

Option 2 also had some advantages. It is (still) needed strongly in this team to create more structure and longevity in the product backlog. We are still in a phase that Henrik Kniberg calls: ‘spoon feeding the team’. The PO is just looking ahead for the next sprint (well, in his mind he has a much longer picture, but he has only time to share the next sprint with the development team). On the downside: the functional support people have a lot of domain knowledge that we want to have very close to the developers.

Therefore we have decided to select option 3. One team picks up all Financial items with the application and handles Imports for new clients. The other team handles Documents and Workflows within the application.

Splitting the team like this is very much like slicing a user story.

Opsplitsen van een Scrum team

De Scrum-guide geeft, mijns inziens terecht, aan dat een Scrum-team tussen de 3 en 9 man groot moet zijn.

Het team dat ik op dit moment begeleid groeide naar 11 man, dus het werd tijd om te splitsen. Dat deden we overigens niet omdat het moet van de Scrum-guide. Zo scrumdamentalistisch zit ons team niet in elkaar. Wel omdat we last kregen van de grootte:

• allereerst heel praktisch, de ruimte waar we zaten als team werd gewoon te klein om er te kunnen zitten met 11 man;
• we merkten ook dat meetings steeds langer werden doordat in een grote groep iedereen toch zijn zegje moet doen;
• en als belangrijkste, het werd vaak onrustig. Te veel interactie tussen teamleden is niet goed. Iedereen luistert toch even met een half oor mee als twee mensen met elkaar in gesprek gaan, als er een gebruiker langs komt met vragen, een stakeholder met wensen, etc.

Na de splitsing merkte we een enorm verschil in de rust rondom het team. Zeker in het kleinere team (4 man) dat in een kleiner, separate kamer ging zitten.

We hebben goed nagedacht over hoe we het team zouden splitsen. We zagen 3 snijvlakken:

1. development versus maintenance, met andere woorden, bouw van nieuwe features versus vernieuwbouw van bestaande features
2. functioneel beheer versus development; het team had 5 ontwikkelaars, 2 testers, 2 functioneel beheerders, 1 scrum master/tester en een product owner. Een optie was om de functioneel beheerders en de PO in een ‘ready-team’ te zetten, naast het development team
3. een splitsing langs technische of functionele onderdelen van ons systeem

Optie 1 was aantrekkelijk en aanvankelijk de voorkeur vanuit de stuurgroep. Het team wordt behoorlijk geremd in de gewenste velocity voor nieuwbouw doordat er continu bugs en kleine praktische verbeterwensen uit de organisatie komen. Nieuwbouw krijgt daardoor niet de rust die nodig is om snelheid te maken.

Het nadeel van optie 1 is echter dat het een perverse mentaliteit oproept. Het nieuwbouw-team mag rommel afleveren omdat het maintenance-team het later wel zal oplossen. Natuurlijk zal niemand dat bewust zo aanpakken. Maar onbewust kan dit gevoel wel ontstaan. Een aanpak waarbij ‘de vervuiler betaalt’, degene die de bugs maakt ze ook moet oplossen leek ons beter.

Optie 2 had ook een paar voordelen. Het is (nog steeds) hard nodig in dit team dat er meer structuur komt in de backlog. We zitten nog in een fase die door Henrik Kniberg ‘spoon-feeding the team’ genoemd wordt, de PO kijkt maar 1 sprint vooruit. Aan de andere kant: de functioneel beheerders hebben veel domein-kennis die bij de developers veel beperkter is. Veel interactie tussen functioneel beheer en development om slimme, werkbare oplossingen te bouwen is noodzakelijk.

We hebben daarom gekozen voor optie 3. Het ene team pakt alle financiële onderdelen op van het systeem en imports van data van nieuwe klanten. Het andere team richt zich meer op documenten en workflows binnen het systeem. Ieder team heeft 1 functioneel beheerder die de PO ondersteunt in het refinen van de user stories.

Deze indeling is in feite een vertical slice. Vergelijkbaar met de manier waarop user stories geplitst moeten worden.

Estimating 100+ user stories within 2 hours

Planning poker is a well known and proven technique to estimate user stories. It is a good technique that I use often with the teams I coach. However, when I have to estimate a lot of stories (30-200), I don’t use it, because it takes too much time.

Estimating so many stories is often needed. For example when starting a new project. The product owner has prepared his backlog, and needs to have a ballpark figure for cost estimates, contract negotiation, etc. Even agile teams have to manage stakeholder expectations.

A good technique to estimate many stories (based on a blog I once read, but can’t find anymore) is the following.

I will print all stories on small cards (A5 or A6 size) and put them in a pile on the table. The developers will then sort all these stories into 3 baskets: small, medium and large. The product owner should be present to explain the content of stories. In my experience, you will need about 1 hour to do this for 70-100 stories. Make sure to facilitate it well, encourage the developers to do it quickly, use their gut feel.

When this first round is done, I will ask them to do it again, one level deeper. So, the small stories get split again in 3 groups: small-small, medium-small and large-small. And so on for the medium and large piles. At the end of this second round at most 9 piles will exist from small-small to large-large. Sometimes, some piles will overlap. Large-small and small-medium may be the same size.

This second round of estimation will be performed much faster than the first round. All stories have been discussed already, so the discussion time is saved. Typically, 30 minutes is enough for this step.

From this point onwards, it is easy to assign story points. If this is the first time you’re estimating and there is no story point baseline yet, you can define the small-small pile as your 1 story point baseline. All stories in that pile are 1 point large.

Now move on to the medium-small pile. How much bigger are they compared to the 1 point stories? Twice, three times? Assign 2 or 3 story points. And so on for all 9 piles.

I find it typical that the large-large stories get real big story point counts. 100 points is no exception. And that is fine. This simply means that these are not really stories, but epics and that they need to be split into smaller stories later on (if their value really outweighs their cost).

Experiences with Retrospectives

Recently I’ve found an excellent website on Retrospectives: Retromat, with a very useful booklet as well (which unfortunately is out of print at the moment). I am now using this as my basis for retros all the time!

Retromat assumes you’re using 5 phases in your retro:

• Set the stage
• Gather data
• Generate insight
• Decide what to do
• Close the retro

For each phase, the site (and the booklet) contain several practical methods you can use to conduct this phase. The site can even generate a random retrospective plan for you 😉

I will use (and extend) this blog-post to share some of my experiences with these techniques.

User Stories / Velocity / Bugs

VRAAG

Nogmaals bedankt voor de cursus, het was echt leerzaam. Ik had nog een kleine vraag m.b.t. storypoints/userstories. Je had aangegeven dat we de kleinste userstory op 1 gingen zetten qua storypoints. Maar zoals het voorbeeld waarbij we de userstory ‘producten bekijken (in die hulpmiddelen winkel) ‘ als 1 hadden geschat wat nu wanneer we een userstory vinden die kleiner is dan de referentie als 1? Wat doe je dan?

Ook hebben we soms sprint overstijgende bugs, hoe definieer je die? als taak (dat wil wel voor de kleine), maar soms is een grote bug een userstory. Hoe ga jij daar mee om?

ANTWOORD

Als je het gevoel hebt dat de kleinste story in de eerste set niet echt heel klein is (meer dan 1-2 dagen werk) en dat er later mogelijk kleinere stories kunnen komen, zet ‘m dan op 2 (of eventueel 3). En gebruik dat dan als de basis. Pas wel op voor overdrijven! Stories van een kwartiertje zijn niet meer zinvol. Veel kleiner dan een halve dag zou ik een story niet maken. Als je toch al begonnen bent met een 1, dan kan je altijd 1/2 als story point gebruiken. Ik ga als volgt om met bugs: 1. kleine puntjes die in de demo gevonden worden, worden meteen opgelost en horen dus gewoon bij de huidige sprint. 2. grotere bugs schuiven als TAAK door naar de volgende sprint. Ik maak er nooit een User Story van. Het gevolg hiervan is dat deze taken geen story points opleveren en dus ten koste gaan van je velocity. Dat is ook ‘je verdiende straf’ voor het introduceren van bugs. Door deze extra taken gaat je velocity omlaag. Daardoor kun je de volgende sprints minder stories oppakken en krijg je vanzelf meer tijd om betere kwaliteit software te bouwen. Dan gaan de bugs eruit, krijg je meer tijd voor stories en stijgt de velocity weer. Eigenlijk een prachtig mechanisme!

Multi-disciplinary teams, not multi-disciplinary persons!

In the teams I am coaching at the moment, I noticed an interesting misunderstanding of the concept of multi-disciplinary (or cross-functional) teams. Or, maybe, it’s more of a caricature than a misunderstanding.

When I state that a good Agile or Scrum team should be multi-disciplinary, this is sometimes interpreted as “so every person in the team should be able to do anything”.

This is wrong! Completely, utterly wrong. It is nonsense!

People have their specialties. Some people are good coders, other good testers. And we really want our team members to be good craftsmen.

But, we need a team that is, as a whole, capable of completely turning a sprint backlog into completion. Into DONE completion.

Some people code, others design, others test.

But it is not the team members who are completely multi-disciplinary, it is the team!

Now, there is more to say about the capabilities of team members. We don’t want super-specialists who can only do one task. We really like to have people with T-profiles. But more on that in a later post.