Webbplatser

Webbplatser ikon

Planering

En sprint innehåller ett antal datum som är kopplade till planeringen av nästkommande sprint. Det är viktigt att dessa tidpunkter hålls eftersom dessa aktiviteter är sekventiella. Det innebär att om nedan aktiviteter förskjuts påverkar det förutsättningarna för planeringsarbetet. Den hårda kopplingen till specifika datum styrs genom kalenderinbjudningar, vilka ger påminnelser om när aktiviteterna ska ske.

Inför sprintplaneringen

Kravställarna (Produktägarna) äger backloggen i DevOps och ser till att alla User Stories är tillräckligt detaljerade för att kunna brytas ner och tidsuppskattas. Kravställarna meddelar utvecklarna vilka User Stories som behöver tidsuppskattas genom att begära estimering.

Det kan vara bra att slänga ett extra öga så att Area Path och Iteration stämmer, annars kommer User Story och ingående Tasks att vara osynliga och, i värsta fall, missas till planeringen.

  • Area: Här ska produkt- eller systemnamnet finnas längst till höger.
  • Iteration: Här ska framgå i vilken iteration (sprint) som leverans önskas, samt vilket team som ska leverera User Storyn. Det finns flera team, exempelvis ”Appl och API”, "Datalager" och ”Integration”. Teamets namn visas längst till höger.

Utvecklarna skapar minst en Task som beskriver de tekniska åtgärder som behövs för att implementera en User Story. Förutom en beskrivning på Tasks sätter systemutvecklaren sin uppskattade tid på “Original Estimate” och “Remaining” samt anger vilken typ av arbete det gäller under “Activity”. Summan av “Original estimate” och “Remaining” kan summeras upp till User Story.

Om en User Story inte är tillräckligt väl beskriven för att tidsuppskattas, måste utvecklaren meddela kravställaren att kompletteringar av User Story behöver göras. En illa förberedd User Story kan komma att gallras bort.

Den uppskattade tiden för genomförande kan ha en stark påverkan på prioriteringen, så först när tidsuppskattningen finns på plats kan kravställarna prioritera sina User Stories.

Arbetet med User Stories och Tasks är något som sker fortlöpande. Det gäller att hålla backloggen levande och aktuell och det är kravställarens ansvar. Arbetet med backloggen fortsätter alltså under hela sprinten parallellt med att nya User Stories läggs till, befintliga förtydligas och prioriteringar diskuteras.

Del 1: Prioritering

Den tredje fredagen i kalendermånaden håller Region Hallands chefsarkitekt ett prioriteringsmöte. Här lyfts alla utvecklingsinitiativ fram för respektive team och dessa diskuteras på nivån Epics och/eller Feature. Utvecklingsinitiativen prioriteras också, sett ur ett regionalt perspektiv.

Deltagare på detta möte är de som har ett behov av systemutveckling, vilket kan exempelvis vara objektledare eller objektspecialister.

Del 2: Grovplanering

På grovplaneringen bestäms preliminärt vilka User Stories som ska tas in i sprinten. De User Stories med tillhörande Tasks som får plats i sprinten läggs över från backloggen till sprinten. Systemutvecklarnas tillgängliga tider har sedan tidigare lagts in i DevOps och dessa matchas mot tidsuppskattningarna, vilket gör att teamet får en beläggning som motsvarar tillgängligheten.

Deltagare på detta möte är chefsarkitekt och den ansvarige för systemutvecklingstjänsten.

Del 3: Detaljplanering

Ett detaljplaneringsmöte hålls för respektive Scrum-team. På detaljplaneringen fördelas respektive Task till personer i teamet och det är här som det slutligen bestäms vilka User Stories som kommer med i sprinten. Respektive systemutvecklares tillgängliga tid under sprinten har sedan tidigare lagts in i DevOps och den matchas mot tidsuppskattningarna, vilket gör att den enskilde individen får en beläggning som motsvarar tillgängligheten.

Deltagare på detta möte är medlemmar från teamet och den ansvarige för systemutvecklingstjänsten.

Senast ändrad: