Categorie Archief Agile

What every Product Owner should know

When I’m participating in an agile team or when I’m doing some agile coaching stuff I often have conversations with the product owner about roles, activities and expectations of his/her job? And during this conversation I advice to read the ‘Product Owner Manual’ from ScrumSense. I don’t think every product owner can or will agree to this manual but it is the first home work I’ll advice.

Product-Owners-Manual

More info: http://www.scrumsense.com/resources/product-owner-manual/

How to split a user story (or slice or use case story or ..)

I found a nice flowchart for splitting a user story. Naturally the same flowchart is applicable for slices or use case stories if you are using Use Case 2.0 techniques.

For more info: http://www.agileforall.com/splitting-user-stories/

 

Visualize progress with charts

A burn-down (or burn-up, or cumulative flow) chart is a graphical representation of outstanding work versus time. The outstanding work is often on the vertical axis, with time along the horizontal. The chart is used in agile software development methodologies like Scrum. With this very simple chart, and in my opinion the only one you need for the team, it is so easy to:

  • predict when all of the work will be completed;
  • see if we are on track;
  • use for early steering;
  • not be surprised at the end of the sprint;
  • stop answering questions about progress;
  • learn for better estimating;
  • start focusing on burning (a.k.a. delivering);
  • create energy in the team.

I also noticed that is very easy to misuse the charts so not the real progress is shown. With that discussion I could fill several other articles. In this article I’ll explain different types of charts with the benefits and concerns of that type, also in this article I will not discuss why measuring progress of work instead of measuring progress of added value.

For now I see three types of charts:

  • Burn-down charts displays the amount of outstanding work;
  • Burn-up chart displays the amount of work done;
  • Cumulative flow chart displays the amount outstanding work and work done (and more).

How to measure outstanding work?

The vertical axis displays often the amount of outstanding work or the work still to do. This can be the

  • time remaining;
  • number of stories still remaining;
  • number of tasks still remaining;
  • amount of user points still remaining.

 

Chart with the time remaining

image

This chart shows every day the time remaining of all work in the sprint. For a correct chart the teams needs to update the remaining time for all items and also continuously re estimate the remaining time. When you only calculate the initially estimated hours minus the hours spent minus the chart will not be accurate. It is possible the chart sais 0 hours remaining and the work is still not done!

Benefits

  • If used with the correct estimated time remaining this chart is the most precise chart. Project managers loves these type of charts
  • A lot of project management tools are supporting this type of chart

Concerns

  • How many stories are finished? You can’t answer this important question from the chart. It looks not that bad – but it could be that no story at all will be finished at the end of the sprint.
  • To draw the chart line daily – you need to re estimate all the work remaining each day. This counting is time consuming and I never met developers who like doing things with hours…
  • When the chart say zero hours left it is still possible no story is finished…
  • Counting hours spent is different form re estimating hours every day.
  • Updating this chart is difficult and so it’s almost impossible to embed it in your the daily standup.

 

Chart with the number of stories remaining

image

This chart shows every day the number of remaining stories. The chart only drops when the story is done.

Benefits

  • To draw the chart daily it’s very easy by counting the stories not done.
  • The charts show the progress of the items the team committed to.
  • It stimulates the team to completely finish the stories.
  • It stimulates the team to finish the story one by one and to eliminate too much work in progress.
  • It is easy to embed it in your daily standup.

Concerns

  • Differences in sizes of the stories is not shown.
  • Law of large numbers doesn’t apply with small number of stories.
  • When all stories are finished at the end of the sprint the chart doesn’t show progress during the sprint.
  • It stimulates the team to complete the small stories first and ignore the priorities.

Chart with number of tasks remaining

Instead of counting stories it is possible to count the remaining tasks.

Benefits

  • To draw the chart daily it’s very easy to count the tasks not done.
  • Chart is displaying growing and shrinking of amount of work.
  • Law of large numbers applies.
  • You can embed it in your daily standup.

Concerns

  • Tasks needs to be the same size (sort of) for a useful chart. (It’s common to split the tasks to same sizes approx half day work).

Chart with amount of story points remaining

image

In my opinion is the chart which is showing the story points remaining my favorite burndown chart. This chart shows the amount of story points remaining for each day.

Benefits

  • To draw the chart daily it’s very easy to count the points not done
  • The charts show the progress of the items the team committed to.
  • Difference in size of the stories is shown.
  • It stimulates the team to completely finish the stories
  • It stimulates the team to finish the story one by one and to eliminate too much work in progress.
  • You can embed it in your daily standup.

Concerns

  • When stories are finished at the end of the sprint the chart doesn’t visualize progress. It’s difficult to see you are on track or predict completion date. With focusing on finishing stories one by one this problem

Dagelijkse 15 minuten stand-up, start-van-de-dag, scrum of flow-sessie

Je bent tegenwoordig géén echt ontwikkelteam meer als je niet elke dag even samen gaat staan om een Stand up – , een Scrum – of een Flow sessie te doen. Als het aan het begin van de dag is wordt het ook wel Start van de dag sessie genoemd. En – hoewel niet dagelijks – de Keek op de week heb ik ook al langs zien komen. Ik ben helemaal voorstander van dit soort sessies, het geeft je de mogelijkheid om je activiteiten in het team te synchroniseren en de communicatie simpel te verbeteren. Iedereen krijgt de kans om op de hoogte zijn van wat er speelt. En vooral belangrijk iedereen krijgt de kans om hulp te vragen!

Wat Wat Wat

Tijdens de stand-up sessie is het de bedoeling om er achter te komen wat er speelt in het team en waar eventueel nog hulp nodig is. Veelal wordt er gebruikt gemaakt van een drietal vragen:

  1. Wat heb je bereikt sinds de vorige bijeenkomst?
  2. Wat ga je doen voor de volgende bijeenkomst?
  3. Wat zijn de obstakels die je nu in de weg staan?

Soms draai ik de vragen om. Dus als eerste Wat zijn de obstakels, dan Wat ga je doen en als laatste Wat heb je bereikt. Ik merk dat deelnemers vaak de meeste zendkracht hebben aan het begin van hun verhaal en dat snel de aandacht van de toehoorders verslapt. Aangezien ik het meest interessants vind waar iemand tegenaan loopt (zodat ik je kan helpen!) en minder interessant vind wat je gisteren hebt gedaan (ik kan je toch niet meer helpen) draai ik de vragen om.

Ongeveer 15 minuten

Een stand-up duurt ongeveer 15 minuten. Er is dus niet veel tijd om iedereen uitgebreid aan het woord te laten. Vooral ingewikkelde inhoudelijke discussie zorgen ervoor dat je heel erg kunt uitlopen.  Het is niet de eerste keer dat ik dan ongeïnteresseerde deelnemers zie staan die soms ook nog even hun facebook of twitter aan het bekijken zijn. Zonde van de tijd dus. De facebook-checkers hadden wellicht beter gewoon aan het werk kunnen zijn! Het is gebleken dat een duur van 15 minuten lang genoeg is. Als je dit dagelijks doet dan komt het niet vaak voor dat er ineens allerlei grote onbekende problemen naar voren komen. Of heeft iemand de vorige sessie staan slapen….? Een 15 minuten sessie betekent wel dat je stand-up gestructureerd moet laten verlopen. Hiervoor heb ik een aantal huishoudelijke regels. Ik pas ze toe als dit nodig is:

  • Één iemand praat de rest luistert. Dus niet iedereen door elkaar heen praten.
  • Wees voorbereid. Wat heb ik ook alweer gedaan gisteren? is niet de juiste opmerking.
  • Privé zaken voor later. Dat je gisteren voetbal hebt gekeken is heel interessant maar bespreek dat op een ander moment.
  • Wijs je sticky note aan. Bij het gebruik van agile dashboards met sticky notes is het handig als de spreker zijn of haar sticky notes ook aanwijst. Deze fysieke beweging zorgt ervoor dat iedereen meteen ziet waar het over gaat
  • Kom op tijd! Dan mag je ook weer op tijd weg en verspeel je niet de tijd van anderen.
  • Focus op het doel. Dit kan het einde van de sprint zijn, de opleverdatum of het zo snel mogelijk de werkzaamheden op  Done te krijgen met zo min mogelijk work-in-progress.
  • Het is geen statusupdate meeting voor de projectleider of andere management. Hiervoor zijn andere middelen. Het is bedoeld is van en voor de teamleden.

Chicken and Pigs

Bij wat grotere teams heb ik het liefst dat alleen de personen aan het woord zijn die werkelijk een bijdrage moeten leveren aan het eindproduct. Natuurlijk zijn andere personen zeer welkom bij de sessie als toehoorder. De bekend agile cartoon over chicken and pigs past hier goed bij http://en.wikipedia.org/wiki/The_Chicken_and_the_Pig . Een Product Owner is wat mij betreft onderdeel van het team. Hij of zij wordt dus ook verwacht bij de stand-up en moet dus ook actief mee doen.

Ritme

Het is goed om de stand-up elke dag op dezelfde tijd en plaats te houden. Het zal dan sneller een gewoonte worden waardoor in het team in een ritme gaat komen. Het kan voorkomen dat iemand een keertje niet kan. Ga vooral door met de stand-up op hetzelfde moment en locatie. Eventueel kan de afwezige vooraf een mede teamlid informeren zodat deze de plek van de afwezige in kan nemen. Dit mag geen gewoonte worden!

Volhouden

Hoewel soms een stand-up als last wordt gevoeld is het toch verstandig om door te zetten. Zodra het blijkt dat tijdens de stand-up geen nieuwe informatie wordt verteld en geen hulp meer wordt gevraagd omdat iedereen al op de hoogte is, dan kun je ervoor kiezen om minder stand-ups te doen. Ik heb dit nog nooit meegemaakt. Er is altijd wel iets te melden of er is hulp nodig. Dus wat mij betreft gewoon volhouden! De enige keer dat ikzelf dacht dat de stand-ups wellicht overbodig ging worden waren juist de teamleden erg enthousiast! Het was de mogelijkheid om te tonen dat het goed ging! De projectleiding en productowner waren toendertijd heel tevreden (en we hoefden geen ingewikkelde excelrapporten te maken met allemaal groene smileys). Als je het goed doet kost een stand-up ook niets. Alle tijd de je investeert levert direct tijd op door de juiste hulp die je krijgt en door de besparing op andere sessies zoals teamoverleg, wekelijks projectoverleg maar ook kennisoverdrachtsessies en andere voortgangsmomenten.

Tips

Tijdens de vele stand-up sessies die ik heb meegemaakt heb ik nog wat leuke tips gevonden die je eventueel kunt toepassen:

  • De laatste persoon die zich aansluit bij de stand-up sessie is degene die sessie faciliteert: Het hoeft niet altijd de scrummaster te zijn en dit kan helpen zodat iederen op tijd aanwezig is.
  • Gebruik een toeter om iedereen te attenderen op de stand-up sessie: Hoewel iedereen zelf de tijd in de gaten kan houden hebben mensen soms moeite om hun werk los te laten..
  • Een stand-up heet niet voor niets stand-up: Als je staat ben je automatisch actiever en alerter. Blijf je achter je bureau zitten dan ben je toch eerder afgeleid.
  • Doorloop niet altijd dezelfde richting. Ga eens de andere kant op.
  • Doe een rondje per product backlog item. Vooral als je een aantal product backlog items hebt ingepland die minder met elkaar te maken hebben.

De stand-up sessie is wat mij betreft één van de technieken in de agile wereld die je gewoon moet doen en geen discussie over de effectiviteit. Alleen de mensen die dit nog nooit goed hebben ervaren twijfelen.

Estimation and planning with smart use cases

Wat zijn smart use cases. Hoe kan kan ik er mee schatten en nog meer informatie. Deze presentatie heb ik gedaan tijdens het smart use cases event van Capgemini in 2008. De slides staan online!

Wil je meer weten over Smart use cases? Wat zijn de verschillen en overeenkomsten met user stories, gewone use cases? Hoe kun je slim en pragmatisch omgaan met specificaties in een agile werkwijze? Neem dan contact met mij op. Ik help je verder!

Presentatie Wat is scrum?

Regelmatig heb ik presentaties mogen geven over Scrum. Ik leg dan uit wat specifiek scrum is, waar bestaat het uit, welke ceremonies zijn en nog veel meer. Veelal vul ik de slides aan met mijn praktijkervaringen en tips van de werkvloer.

In 2008 heb ik een presentatie gegeven bij Capgemini en deze staat online!

Wil je meer weten over Scrum? Wat zijn de verschillen en overeenkomsten met Scrum, agile en waterval en hoe kun je scrum implementeren en gebruiken in je organisatie? Neem dan contact met mij op. Ik help je verder!