Slut
Sprintslut
I en perfekt sprint finns det varken öppna buggar eller user storys kvar. Men i verkligheten har man kanske både en User Story och ett par buggar kvar som man inte hunnit stänga i sprinten. Dessa måste hanteras innan sprinten tar slut, ofta genom att de flyttas över till kommande sprintar. Det är viktigt att utvecklaren planerar sitt arbete extra noga mot slutet av sprinten så att det vid sprintslut går att leverera genomförda User Stories. Det är väldigt viktigt att utföraren, via diskussionsfunktionen i Azure DevOps, meddelar beställaren om det finns User Stories som inte kommer att levereras.
Här nedan finns exempel på olika situationer och hur de bör hanteras.
Alla Tasks i en User Story hinns inte med
Händelse | DevOps |
Alla Tasks för en User Story hinns inte med i Sprinten. |
Utvecklaren låter status på User Story fortsatt vara ”Active”. User Story ligger kvar i ursprungssprinten, men ofärdiga Tasks flyttas över till nästa iteration.
Beställaren meddelas och tag sätts på User Story. |
User Story är färdig och ligger i Testmiljön, men hinner inte testas
Händelse | DevOps |
Testerna hinns inte med sprinten. |
Status på User Story får fortsatt vara ”Resolved” och alla Tasks får fortsatt ha status ”Closed”. Däremot så skapas två nya Tasks, Buggrättning och Produktionssättning på samma User Story.
Dessa Tasks har status ”New” och flyttas fram till nästkommande sprint. |
User Story har godkänts för produktionssättning, men det finns
inte tid för produktionssättning
Händelse | DevOps |
Färdig User Story som godkänts för produktionssättning, men som inte hinns med att produktionssättas. | User Story ligger alltid kvar i ursprungsspriten med oförändrad status. Skapa en ny Task i nästkommande sprint med status ”New”; Produktionssättning. |
Senast ändrad:
