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

Posted in Agile, Scrum | Leave a comment

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 ststory-point-rulerory 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.

Posted in Uncategorized | Leave a comment

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é

Posted in Agile | Leave a comment

Splitting up a Scrum team

1663686471The 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.

Posted in Agile, Scrum, software engineering | Leave a comment

Opsplitsen van een Scrum team

1663686471De 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.

Posted in Agile, Scrum | 2 Comments

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.IMG_1325

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).

Posted in Uncategorized | Leave a comment

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. Continue reading

Posted in Agile, Scrum | Tagged | Leave a comment