Werken in sprints is ontstaan vanuit de Scrum methode. Het maakt cyclisch werken in korte periodes mogelijk en bevordert de agile ontwikkeling van software. Hoe lang alle sprints in een project duren, wordt van tevoren bepaald. Dit ligt meestal tussen de 2 en 4 weken. Elke sprint maken we een nieuwe sprintplanning, voeren we in die periode het werk uit en eindigen we met een review.
Werken in sprints: Tijdig bijsturen zodat onze klanten altijd weten waar ze aan toe zijn
Bij 10KB ontwikkelen we software in ‘Sprints’. Door alle projecten waar we aan werken op te knippen in korte periodes, maken we het mogelijk om snel te schakelen, houden we altijd goed voor ogen wat er nog moet gebeuren en behouden we de flexibiliteit om projecten ad hoc aan te passen zodat we optimale resultaten behalen.
Wat is een sprint?
Starten met een planning
Aan het begin van elke sprint maken we een zogenaamde sprintplanning. Hier leggen we in detail vast wat we in de komende sprint gaan doen. Op basis van prioriteit en doelen maken we tickets aan in Jira, maken we inschattingen hoeveel werk deze tickets in beslag zullen nemen en zo vullen we in samenspraak met de klant gemiddeld zo’n 80 tot 120 uur werk in voor de komende sprint. Dit werk zetten we vervolgens op een testomgeving zodat onze klanten altijd toegang hebben tot hun eigen code.
Continu evalueren
Aan het eind van elke sprint volgt weer een nieuwe sprint. Dit geeft regelmatig evaluatiemomenten over voorgaande momenten. Wat ging er afgelopen sprint goed? Moeten er in deze sprint nog zaken opgepakt worden die de afgelopen periode zijn blijven liggen? Al deze zaken kunnen vervolgens meegenomen worden in de nieuwe sprintplanning.
Duidelijke verwachtingen
Omdat we elke sprint kijken waar we staan, komen we niet zo snel voor verrassingen te staan. Van tevoren bepalen hoeveel uur we nodig zullen hebben voor een project is altijd een schatting en het kan natuurlijk altijd gebeuren dat iets meer of minder werk is. Doordat we elke keer een nieuwe planning maken, zien we het vaak al van ver aankomen als die schatting afwijkt en welke keuzes daarvoor verantwoordelijk zijn. Daardoor kunnen we ruim op tijd bijsturen waar nodig. Kostte iets minder tijd dan verwacht? Dan hebben we extra ruimte om randzaken op te pakken. Blijkt een project meer inspanning te kosten dan oorspronkelijk verwacht? Dan kunnen we kijken (in samenspraak met de klant) waar we de prioriteit gaan leggen. Zijn er bijvoorbeeld onderdelen minder belangrijk die we kunnen schrappen, zodat we binnen budget kunnen blijven?
