Menu Close

Tilgange til Sprint planning i Scrum

Det er et faktum, at Scrum frameworket er det foretrukne rammeværk (se figur 1) for langt de fleste agile transformationer, og for mig er det let at se, hvorfor det er så populært.

Figur 1: kilde – 15th State of Agile report, side 13

Scrum Guiden er på omkring ti sider på print, hvilket gør det let at overskue teorien bag, men den er dog noget sværere at mestre i praksis.

Det primære formål med Scrum er at hjælpe personer, teams og organisationer med at levere værdi.

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

– Scrum Guide 2020

Jeg er ofte stødt på Scrum Teams, som anser Scrum frameworket for værende for rigid til kortsigtet planlægning i forhold til f.eks. Kanban eller XP. De nævner især den måde, de “skal” planlægge på, når de bruger Scrum.

Er planlægning med Scrum virkelig for rigid? Er der egentlig begrænsninger på mulige tilgange til at lave en Sprint planlægning i Scrum?

Begrænser Scrum Guiden mulighederne i Sprint Planning?

For noget tid siden, blev jeg igen nysgerrig på selve Sprint Planning eventet og hvad Scrum Guiden egentlig skriver om det. Det der vækkede min nysgerrighed var egentlig, at jeg gerne vil gøre op med den store misforståelse, jeg oplever, der er blevet skabt omkring velocity.

Sprint Planning

Når jeg nærlæser Scrum Guiden, så er der ikke noget, der fortæller mig, hvordan et Scrum Team skal udforme deres Sprint Backlog (SBL). Jeg synes rent faktisk, at den lægger op til, at det er noget de enkelte teams gør på deres måde.

Sprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.

The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.

– Scrum Guide 2020

Forskellige tilgange til Sprint Planning

Jeg har igennem årene været vidne til, at Scrum Teams har forskellige tilgange til at lave den indledende plan for deres SBL, og med den forsøge at skabe det rette fokus. Fokus er som bekendt en af de fem Scrum values.

Det essentielle her er, hvad fokus er på. Er fokus på output eller outcome?

Throughput

Throughput bruges ofte i Kanban til at forecaste, hvor mange items et team kan færdiggøre i en afgrænset tidsperiode.

Throughput fortæller heller ikke noget om teamets værdiskabelse, så derfor vil jeg påstå, at den er fokuseret på output frem for outcome.

Velocity

Velocity ser jeg oftest anvendt, som det foretrukne værktøj til at forecaste den indledende plan for et sprint. Her bliver Yesterday’s Weather i kombination med story points oftest anvendt som guideline, når teamet kommer ud af en Sprint planning.

For mig siger velocity intet om værdiskabelse, du kan ikke måle et teams performance eller værdiskabelse på baggrund af deres velocity. Derfor vil jeg påstå, at velocity også fokuserer på output frem for outcome.

Figur 2: Indledende plan baseret på velocity eller throughput.

Alligevel ser jeg stadig virksomheder, som vælger at anvende velocity som en key metric.

Jeg ser udelukkende velocity som et understøttende værktøj til at hjælpe et team med at forecaste, det har aldrig været hensigten, at et team skal planlægge så tæt så muligt på deres velocity.

Sprint Goal

Med udgivelsen af den aktuelle Scrum Guide, tilbage i novmeber 2020, blev der tilføjet “commitments”, hvor Sprint Goal er et af dem.

Sprint Goal som et commitment er med til at skabe og sikre fokus på værdiskabelsen, så det opmuntrer Scrum Teamet til at arbejde sammen i stedet for at arbejde på seperate initiativer.

Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it. The Sprint Goal also creates coherence and focus, encouraging the Scrum Team to work together rather than on separate initiatives.

– Scrum Guide 2020

Desuden kan et sprint blive annulleret af Product Owneren, hvis et Sprint Goal ikke længere er det rette.

A Sprint could be cancelled if the Sprint Goal becomes obsolete.

– Scrum Guide 2020

Når jeg nærlæser Scrum Guiden, så er der flere steder, som for mig indikerer, at Sprint Goal bør anvendes til at udforme SBL under Sprint planning.

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

– Scrum Guide 2020

Sprint Goal beskriver, hvorfor vi overhovedet skal have det næste sprint og den værdiskabelse teamet vil levere til stakeholders.

The Sprint Backlog is a plan by and for the Developers. It is a highly visible, real-time picture of the work that the Developers plan to accomplish during the Sprint in order to achieve the Sprint Goal.

– Scrum Guide 2020

Her står rent faktisk, at din SBL er en plan, som er lagt af Developers for at nå teamets Sprint Goal.

The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog.

– Scrum Guide 2020

Det fik mig til at reflektere over om måden, jeg tidligere har planlagt et sprint kunne gøres anderledes og i sidste ende skabe endnu mere fokus på værdiskabelse gennem hele sprintet.

Jeg endte ud med at stille mig selv dette spørgsmål, “bør vi så kun tilføje Sprint backlog items, som er et krav for at nå vores Sprint Goal?”.

I figur 3 har jeg forsøgt at illustrere et muligt scenario til mit spørgsmål.

Figur 3. Indledende plan baseret på Sprint goal.

Konklusion

Jeg mener ikke, at der er begrænsninger i de tilgange, dit team kan vælge at have i Sprint planning. Baseret på min erfaring vil jeg dog anbefale at anvende Sprint goal som den primære kilde for at skabe ekstrem fokus på værdiskabelse, og så finde andre værktøjer til at understøtte jer yderligere om nødvendigt.

Du kan ikke altid anvende Sprint Goal only til din indledende plan, fordi der kan forekomme situationer, hvor ikke alle Developers fra start kan bidrage til at nå Sprint goal. Her vil det være naturligt også at tilføje andre PBIs til jeres SBL.

Jeg mener, at det kan give værdi at kombinere Sprint goal og velocity til at udforme jeres SBL. Hvor velocity dog udelukkende bruges til at guide Developers i forhold til Sprint Goal. Hvis Developers identificerer Sprint goal items, hvor den samlet kompleksitet overstiger deres velocity, så kan det give anledning til at stoppe op og lige vende Sprint goal og om det er realistisk at nå i ét sprint.

Jeg er meget interesseret i at høre jeres holdninger og erfaringer på området, da jeg er overbevist om, at det kan være med til at give mig og andre nye perspektiver på Sprint planning.

Leave a Reply

Your email address will not be published.

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.