Sprintslut
I en perfekt sprint finns det varken öppna buggar eller User Stories 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 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: