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!

Posted in Agile, Scrum | Tagged , | Leave a comment

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.

Posted in Agile, Scrum, Uncategorized | Leave a comment

Why use story points?

Why do we use Story Points?

Story points are often used as unit of estimation in Scrum projects. Why do we use them, and what is the advantage of story points over estimates in hours?

To answer that question, we should first look at the concept of Velocity. Because, having good story points allow you to work with a useful definition of velocity.

Let’s use an analogy to illustrate this.

Gouda-NiceSuppose you plan a holiday trip by car from Gouda (where I happen to live) to Nice in France. Google maps quickly shows you that the whole trip is 1351 km. A quick estimate for the duration of the trip is then easily derived. We estimate our average velocity to be 100 km/h (I usually drive a bit faster, but I’ve learned through experience that you are often hindered on the road, and usually don’t get much faster than this on average).

So, the total trip will take some 13,5 hours driving time. Let’s add some 2 hours of rest, and we can estimate our time of arrival.

So, now we have a plan for the project, we know the total size of the project (1351 km) and we have an estimate for the duration (15,5 hours).

During the trip, we want to track our progress.

Tracking progress in hours is stupid. If I hit a big congestion already at Rotterdam, and get stuck for 2 hours, my ‘progress’ in hours will be 2 hours, but my real progress is almost nothing. Tracking progress in hours will not help me to re-estimate my arrival time (except, when everything runs perfectly according to plan).

The only thing that makes sense in tracking progress is in tracking results. We could do this by watching the number of kilometres on the dashboard, but that feels a lot like micromanagement. You can’t keep your eyes on the dashboard all the time; you need to watch the traffic.

A much better way is to plan some milestones at regular distances at the track:

Milestone Distance (km) Duration (h) cumulative
Antwerp 100 1
Brussels 150 1,5
Luxemburg 350 3,5
break 4,5
Nancy 500 6
Dijon 700 8
Lyon 900 10
break 11
Orange 1100 13
Marseille 1200 14
Nice 1350 15,5

Please note:

  1. The milestones are not all at exactly the same distance. It would be nice that all major cities on my journey we at exactly 100 km distance, but, that’s simply not the reality.
  2. My estimates for distance are not exact, but rounded at 50 km. More exact estimates are not needed anyway. While driving, I never know exactly if I have reached Nancy or not. I may first reach the exit Nancy-north, then Nancy-centre and finally Nancy-south. If I arrive at any of these exits at roughly 6 hours after my departure, I know I am still on track. Estimating distances, and thus durations at a finer granularity will only cause me to micromanage my trip: “I am 3 minutes late!” which is only detracting me from my real progress.

So, back to software projects.

The velocity is the average number of story points that a team can deliver in a sprint (similar to my average speed of 100 km/h).

A story point is an indication of the size/duration of the tasks that we perform in a sprint. Stories should be small enough to give us sufficient milestones during the sprint to measure our progress. My personal taste is that 6-10 stories per sprint is a good number.

Fewer stories (and certainly less than 3) has some disadvantages:

  • I cannot predict in any serious level of detail if I will achieve everything I have planned in this sprint
  • There is a good chance that the last story in this sprint will not be completely delivered. If that happens, I have failed 50% or 33% of my sprint. That is a lousy result. If I did have 10 stories and missed the last one, I had a 90% result. Although not perfect, this is still a good result.

More stories means more administration, and we all hate administration, don’t we?

So, why do we use story points?

  • We want to track business value (story points), not cost (hours). Tracking cost is useless, cost simply increases with time (our team is in place, their hours are consumed, their salaries are paid) regardless of any progress made.
  • Estimating relative values (is this task twice as big as that task?) is much more easy for people to do.
  • Story points lead to a useful velocity indication, which increases when we learn how to work smarter.
  • The velocity will include all typical disturbances (getting coffee, regular meetings, typical interrupt levels) without the need to administer separately, so less bureaucracy.
Posted in Agile, Scrum, software engineering, Uncategorized | Leave a comment

Hoe kan ik veel User Stories snel inschatten?

Planning poker is een bekende techniek om de grootte van User Stories in te schatten. En het is een goede techniek. Maar als ik veel (30-100) stories moet inschatten, dan duurt het pokeren me te lang. Continue reading

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

Agile bibliotheek

Onderstaande boeken zijn de laatste jaren mijn inspiratie geweest voor Agile, Scrum en Kanban werk.

Continue reading

Posted in Agile, Scrum, Uncategorized | Tagged , , | Leave a comment

Volgorde van de backlog


De product backlog hoort geordend te zijn. Dingen die als eerste opgepakt moeten worden staan bovenaan, wat later mag komen staat onder.

In het algemeen wordt als advies gegeven dat de items op volgorde van waarde moeten staan.

In mijn ervaring is dat echter te beperkt. Wat mij betreft bepaalt een mix van de volgende factoren de volgorde van de backlog:

  • waarde – de waarde die de stories hebben voor de klant of gebruiker; meestal vraag ik de product owner om aan alle stories een getal toe te kennen (100 voor heel veel business value, 1 voor heel weinig);
  • risico – spannende stories waar mogelijk ellende in zit moeten relatief hoog op de lijst staan; fail fast is beter dan fail late;
  • technische afhankelijkheden – er is nu eenmaal vaak een bepaalde technische volgorde om dingen te bouwen.

In de keuze van backlog items voor de komende sprint komt er nog een aspect bij: het werkt veel prettiger als de items waaraan in een sprint gewerkt wordt aan elkaar gerelateerd zijn. Iets als: “In sprint 4 doen we rapportage, in sprint 5 implementeren we het zoeken”. Een sprint goal zorgt ervoor dat het team meer focus krijgt, meer gaat samenwerken tijdens de sprint en het leidt tot veel interessantere demo’s.

Posted in Agile, Scrum | Leave a comment

Scrum rammelt #2 – door de bomen het bos niet meer zien

Recent mocht ik een organisatiediagnose uitvoeren bij een organisatie waar al lang Scrum werd toegepast. Het project dat ik onder de loep nam was inmiddels bij Sprint 66. Indrukwekkend!

Tijdens mijn interviews kwam allerlei ellende naar boven:

  • per sprint werd een design bijgehouden in een Wiki, maar elke keer werd een nieuw stukje design gemaakt voor dit sprintje (soms zelfs voor 1 user story), waardoor een onleesbaar versnipperd design ontstond dat geen enkel nut meer had;
  • er was nauwelijks klantkontakt in de sprints;
  • een scheve verhouding ontwikkelaars – testers;
  • vervelende beperkingen in admin-rechten voor ontwikkelaars en beperkte ontwikkel-tools;
  • onnodige overhead in review procedures.

Allemaal zaken die ik eigenlijk niet meer verwacht had bij een team dat inmiddels 66 retrospectives had uitgevoerd. Dat deden ze in ieder geval wel consequent!

Toen ik mijn verbazing uitsprak begon men zich zelf ook eens achter de oren te krabben. Dat was inderdaad wel vreemd.

Na wat nadenken bleek dat men zich in de retrospectives steeds alleen maar had geconcentreerd op de afgelopen sprint en nooit eens goed gekeken had naar de stand van het hele project. De bovengenoemde ellende betrof deels zaken die echt op projectniveau spelen (en minder op sprint niveau), of zaken waar men zich na een aantal sprints bij had neergelegd (dat gaat hier nu eenmaal zo). Elke sprint werd wel naar de bomen gekeken, maar het bos was uit het oog verloren.

Advies: als je echt een groot project gaat doen (meer dan ongeveer 10 sprints), plan dan om regelmatig (bijvoorbeeld elke vierde sprint) naar het hele bos te kijken in de retrospectives.

Posted in Agile, CMMI, Scrum | Tagged | Leave a comment