8,4 / 10 187 beoordelingen op Springest
030-2308900 info.nl@inspearit.com

Veel voorkomende pitfalls waar Scrum Masters intrappen - Deel 2

De vorige blog ging over de pitfalls bij de Product Backlog, vandaag gaan we verder met de Sprint Planning.

Pitfalls bij de Sprint Planning

De regels van Scrum zijn niet ingewikkeld, ze staan uitgelegd in de Scrum Guide, een document van 21 pagina’s. Scrum op een juiste manier uitvoeren is echter een stuk lastiger. Er zijn vele valkuilen voor de Scrum Master. De belangrijkste vind je in een blogreeks waar dit de eerste blog van is. We gaan er tijdens onze Scrum Master Training natuurlijk ook verder op in op deze valkuilen.

Naast dat je als Scrum Master de Product Owner dient, dien je ook het Ontwikkelteam op een aantal manieren waaronder:

  • Coachen van het Ontwikkelteam op het vlak van zelforganisatie en multidisciplinair werken;
  • Het faciliteren van Scrum events wanneer gevraagd of nodig;

Het eerste Scrum event dat je als Scrum Master in een Sprint faciliteert, is de Sprint Planning. Tijdens de Sprint Planning wordt het werk, dat uitgevoerd moet worden tijdens een Sprint, gepland. Het maken van dit plan is een gezamenlijke inspanning van het gehele Scrum Team. Daar hoor jij als Scrum Master dus ook bij. Maar er kan veel misgaan:

#1 - De sprint planning duurt te lang 

Dit heb ik als lid van een Ontwikkelteam zelf meegemaakt toen ik voor een Nederlandse telecomprovider met collega’s uit Nederland en Italië een iPhone en Android app maakte. De Sprint Planning, die elke 4 weken in Rome was, duurde van een uur of 9 ’s ochtends tot een uur of 8 ‘s avonds. In een te kleine meeting room in een niet al te modern kantoorpand met plat dak. In de zomer. In Rome. Zonder airco. Aan het eind van de meeting hadden we alle User Stories in taken verdeeld, terwijl dit helemaal niet nodig is volgens de scrum guide: 

“Aan het einde van deze meeting heeft het team het werk voor de eerste dagen van de Sprint opgedeeld in onderdelen, vaak van één dag of kleiner. Het Ontwikkelteam organiseert zichzelf om het werk in de Sprint Backlog gedaan te krijgen, zowel gedurende de Sprint Planning als gedurende de Sprint.”

Als de timebox voorbij is stopt de Sprint Planning. Hierna (vaak, maar niet per definitie, de volgende dag) kan het Ontwikkelteam beginnen met het werken aan het Sprint Doel (zie de volgende pitfall). Product Backlog Items (PBI’s) die nog niet in onderdelen zijn opgesplitst tijdens de Sprint Planning, worden tijdens de Sprint door het Ontwikkelteam opgesplitst.

#2 - Geen Sprint Doel definiëren 

Als Scrum Master ben je er verantwoordelijk voor het promoten en ondersteunen van Scrum zoals het staat beschreven in de Scrum. Daar valt het Sprint Doel ook onder. Sterker nog, zonder Sprint Doel ben je volgens de definities van de Scrum guide geen Scrum aan het doen: 

“De rollen, gebeurtenissen, artefacten en regels van Scrum staan vast. Hoewel het implementeren van delen van Scrum mogelijk is, is het daaruit volgend resultaat geen Scrum. Scrum bestaat slechts als geheel […]”

Het niet definiëren van het Sprint Doel lijkt een klein dingetje (het is vaak ook maar één zin), maar het is wel een belangrijk onderdeel van Scrum: het is de doelstelling die gehaald gaat worden in de Sprint, het geeft richting aan het Ontwikkelteam waarom ze het Increment bouwen. Het geeft meer ‘purpose’ aan een Sprint dan 8 PBI’s die niks met elkaar te maken hebben maar toevallig bovenaan de Product Backlog stonden omdat 8 stakeholders tevreden moeten worden gehouden.

Je kunt het Sprint Doel zien als Elevator Pitch: een korte samenvatting over waar het Ontwikkelteam mee bezig is deze sprint. Hiermee forceert het Sprint Doel samenhang tussen de geselecteerde PBI’s af, en daarmee ook een clustering van PBI’s in de Product Backlog. 

#3 - Push ipv pull in de Sprint Planning 

Als Scrum Master coach je het Ontwikkelteam op zelforganisatie. Onderdeel hiervan is ervoor zorgen dat het Ontwikkelteam niet meer werk oppakt (of nog erger: naar zich toe geschoven krijgt) dan zij in een Sprint kunnen opleveren. Een Ontwikkelteam mag best een beetje uitgedaagd worden, maar zou nooit onder druk moeten worden gezet. De kans dat de Sprint te vol raakt is dan te groot, met als mogelijk gevolg dat 100% van het werk 80% af is en gebruikers niks geleverd krijgen. Het kan ook ten koste van de kwaliteit gaan, wat potentieel voor veel rework zorgt, zoals aan bugs en hotfixes. 

Het aantal items dat wordt geselecteerd van de Product Backlog is volledig aan het Ontwikkelteam. Alleen het Ontwikkelteam kan inschatten wat zij kan bereiken binnen de aankomende Sprint. Het Ontwikkelteam haalt dus werk van de Product Backlog de Sprint in; er is geen push vanuit Product Owner, stakeholders of wie dan ook. 

#4 - PBI’s die niet “Ready” zijn (geforceerd) in een Sprint op laten nemen 

De Scrum Master is ervoor verantwoordelijk het Scrum Team de noodzaak laten inzien om duidelijke en beknopte PBI’s te maken. Er ligt ergens een optimum in hoe beknopt of uitgebreid een PBI is. Te uitgebreid is niet goed, er gaat veel tijd in zitten, en we weten pas zeker dat een PBI wordt opgepakt als hij wordt geselecteerd in de Sprint Planning. Misschien wordt de PBI wel nooit opgepakt, omdat blijkt dat hij niet meer nodig is door veranderende marktomstandigheden. Mooi zonde als er dan al vele uren in zitten. 

Te beknopt is ook niet goed. Alle informatie die nodig is om een PBI binnen een Sprint af te kunnen ronden, zou beschikbaar moeten zijn. De Product Owner en Ontwikkelteam zijn er samen verantwoordelijk voor dat tijdens Product Backlog Refinement voldoende details aan de hoogst geprioriteerde PBI’s worden toegevoegd, zodat het Ontwikkelteam zo’n item in één Sprint kan afronden.

#5 - Als Scrum Master meedoen met schatten van PBI’s 

De scrum Guide schrijft voor dat alle PBI’s een inschatting van omvang hebben, en dat het Ontwikkelteam hiervoor verantwoordelijk is. Als Scrum Master ben je niet degene die werkt aan het increment. Je hebt dus ook niet voldoende kennis om PBI’s in te schatten. Tenzij je naast je Scrum Master rol ook onderdeel bent van het Ontwikkelteam.

#6 - Geen procesverbeteringen opnemen in de Sprint Backlog

Sinds de update van november 2017 staat expliciet in de Scrum Guide dat er tenminste één procesverbetering met hoge prioriteit, die in de vorige Retrospective is geïdentificeerd, in de Sprint Backlog moet worden opgenomen. Op deze manier garanderen we de continue verbetering van het Scrum Team.  

Het belang van deze verandering heb ik in 2016 zelf mogen ervaren bij een Marketing en Communicatie Scrum Team. De Product Owner hield een procesverbetering tegen omdat er volgens haar focus zou moeten zijn op het draaien van productie. Tijdens een vakantie van de Product Owner heeft het Ontwikkelteam de procesverbetering doorgevoerd, met als gevolg dat de velocity in 3 sprints tijd van 26 naar 52 naar 73 story points per Sprint ging.


De volgende keer gaan we verder met SM pitfalls bij de Daily Scrum.

Heb je nu vragen over, of wil je doorpraten over een van bovenstaande pitfalls? 

Laat dan een berichtje achter onder de LinkedIn post van deze blog, of bel 030 - 20 20 833.


Stefan Kennedie


Stefan is een enthousiaste Scrum en Agile consultant en trainer die veel ervaring heeft in het trainen en coachen van professionals voor wie Agile en Scrum nieuw zijn. Hij heeft uitgebreide ervaring in het toepassen van Scrum bij organisaties buiten het IT-domein.

DEEL DIT ARTIKEL
VOLG ONZE BLOGS

Gerelateerde blog artikelen

  • Veel voorkomende Pitfalls waar Product Owners in trappen - Deel 4

    De regels van Scrum zijn niet ingewikkeld, ze staan uitgelegd in een document van 21 pagina’s. Scrum op een juiste manier uitvoeren is wel ingewikkeld. Er zijn vele valkuilen voor de Product Owner. Pitfalls tijdens de Sprint Review.

    Lees verder
  • Opleiding toegelicht - Advanced Scrum Master

    Onlangs heb ik samen met collega Ruud Bruls voor de tweede keer dit jaar de tweedaagse training Advanced Scrum Master gegeven. Dit is misschien wel de leukste training die ik bij cibit academy geef.

    Lees verder
  • Veel voorkomende pitfalls waar scrum masters intrappen - Deel 3

    Een dagelijks terugkerend ritueel, de Daily Scrum. Een zeer waardevol moment mits het goed wordt gefaciliteerd.

    Lees verder
  • Veel voorkomende Pitfalls waar Product Owners in trappen - Deel 5

    De regels van Scrum zijn niet ingewikkeld, ze staan uitgelegd in een document van 21 pagina’s. Scrum op een juiste manier uitvoeren is wel ingewikkeld. Er zijn vele valkuilen voor de Product Owner. Pitfalls tijdens de Sprint Retrospective.

    Lees verder
  • Veel voorkomende Pitfalls waar Product Owners in trappen - Deel 2

    De regels van Scrum zijn niet ingewikkeld, ze staan uitgelegd in een document van 21 pagina’s. Scrum op een juiste manier uitvoeren is wel ingewikkeld. Er zijn vele valkuilen voor de Product Owner. Pitfalls bij de Sprint Planning.

    Lees verder
  • Veel voorkomende Pitfalls waar Product Owners in trappen - Deel 1

    De regels van Scrum zijn niet ingewikkeld, ze staan uitgelegd in een document van 21 pagina’s. Scrum op een juiste manier uitvoeren is wel ingewikkeld. Er zijn vele valkuilen voor de Product Owner. Pitfalls bij de Product Backlog.

    Lees verder
  • Veel voorkomende pitfalls waar Scrum Masters in trappen – Deel 4

    Help je Ontwikkelteam om de Sprint goed uit te voeren. Als Scrum Master moet je veel dingen doen, maar soms ook dingen laten.

    Lees verder
  • Veel voorkomende Pitfalls waar Product Owners in trappen - Deel 3

    De regels van Scrum zijn niet ingewikkeld, ze staan uitgelegd in een document van 21 pagina’s. Scrum op een juiste manier uitvoeren is wel ingewikkeld. Er zijn vele valkuilen voor de Product Owner. Pitfalls tijdens de Sprint.

    Lees verder
  • Veel voorkomende pitfalls waar Scrum Masters in trappen – Deel 5

    Hoe kun je het beste terugkijken op de productontwikkeling? Bekijk de tips om een goede Sprint Review te doen.

    Lees verder
  • Veel voorkomende pitfalls waar Scrum Masters in trappen – Deel 6

    Tips voor de scrum master om de Sprint Retrospective goed te begeleiden.

    Lees verder
  • Veel voorkomende pitfalls waar Scrum Masters in trappen – Deel 1

    De regels van Scrum zijn niet ingewikkeld, ze staan uitgelegd in de Scrum Guide, een document van 21 pagina’s. Scrum op een juiste manier uitvoeren is echter een stuk lastiger. 

    Lees verder
  • Agile buiten de IT wereld

    De term Agile komt uit wereld van de software ontwikkeling, maar het gedachtegoed is de IT inmiddels ontgroeid blogt Stefan Kennedie. Waar wordt agility inmiddels toegepast? Is dat alleen in ons werkende leven, of ook al daarbuiten?

    Lees verder

Cookies op de website van Inspearit

Wij plaatsen functionele cookies, om deze website naar behoren te laten functioneren, analytische cookies waarmee wij het gebruik van de website kunnen meten en cookies van derden voor het weergeven van emdeded media (YouTube en GoogleMaps) Hieronder kan je aangeven welke andere soorten cookies je wilt accepteren:

Meer informatie