The lifecycle of an agile sprint

www.optier.comwww.optier.com

The lifecycle of an agile sprint

Step-by-step guidelines

April 8, 2023 v. 3a © 2012 OpTier. All rights reserved.


Agile manifesto

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan


Participants in the agile process

• PM (Product Manager)



• PO (Product Owner)



• Scrum Master



• The Team


Before the sprint• PM and Product Owner prepare the Product Backlog

– Prioritized list of epics (features) broken to ~1 month pieces - PM– Break epics to small user stories – PO

• A user story is a small and testable customer requirement. It will usually look like this:– As a shopper on our site

I want to delete items out of my shopping cartSo that I don’t purchase extra items that I decide I don’t want

• The team get together for a Sniffing Meeting - Optional– Familiarize with the user stories– Ask questions and start thinking about them at night ;)

7


Feature

Feature

Feature

Feature

Feature

Feature

Feature

Feature

US US US US


Day 1• Sprint Planning

– The team meet and go over the Product Backlog (according to priority)

– Get an understanding of each user story– The team members agree on the content of the sprint - this

creates the Sprint Backlog– Submit requests for automation infrastructure enhancements

9


Sprint has started – Tester• Tester starts with writing the tests for the user story

– For new feature: prepare test plan– Acceptance tests: business-facing tests (from the customer point

of view), which make sure that the functionality is like the customer wanted to

– Technology oriented tests: drill down and understand how the user story is going to be implemented, add tests at a lower level

– Scalability tests: are there implications on Load, Overhead, etc?– Any other relevant test (usability, stress, ..)

• PO + Developer + Tester = BFF– Questions about requirements, implementation and so on should

be shared between the people in the team who deal with that user story

10


Sprint has started – Developer• In parallel to the tester, the developer starts coding the

user story– Implement Unit Tests before you code, add more as you code– Add automation functional/integration tests to complete the

testing coverage

• When the tester finished writing the tests– Developer and Tester go over the list, see that it is complete, and

divide the tests between them• Manual tests done by the tester• Automation functional/integration tests done by Dev (some testers might

help). These tests should be the ones who are important to be part of our regression suite

11


During the sprint (1)• Daily Standup Meeting

– Short meeting (15 min) to update on yesterdays process and todays plan

– Bring up issues which prevent you from completing your task on time

• A bug was found– Tester shows the bug to the developer– If the developer says he will fix it on the same day, no need to

open a bugzilla ticket– Otherwise, tester will open a bug– If end of day arrives and developer wasn’t able to fix the bug, he

should open a ticket in bugzilla– Tester and developer will decide on severity and priority together

12


During the sprint (2)• The teams ultimate goal is to complete as many user

stories as possible (bring them to DONE)– Let’s say the sprint ends in 2 days, and we have a user story

which needs 2 more testing days, what options do we have to complete it?

• Move a tester from a task which he won’t finish this sprint (for example he’ll need 4 days to complete it) to working on this task which is 2 days

• Have a developer help with testing, instead of him starting to code a new user story

• etc..

13


When is a story really DONE?• Design complete• Test plan and scenarios complete and documented• Development complete• Develop automation test scenarios for new code• Tests executed• Regression suite runs and completes without issues

(functional)• Bugs: No major, critical, or blockers• Bugs: Normal bugs should be fixed to the extent that PM,

Support are happy to release user story to customers• Dev documentation outlined (tech writing will complete

later)14

(This is called Done-Done)


Keeping track of our progress• We use a Kanban board which reflects the stages a user

story has to pass from ready (left) to done-done (right)

15


End of sprint – Review• The team demonstrates what had been accomplished in

the sprint• This is a live demo, where the functionality is shown to a

group of stakeholders in order to get feedback and make sure the requirements were implemented correctly

• Participants: The team, Product Owner, PM, Support, Field Representatives + Anyone who wishes to join

• In this meeting it can be decided that a story didn’t meet the done definition, and is therefore not done

16


End of sprint – Retrospective• A meeting of the team at the end of each process (in this

case – end of sprint) to discuss:– what was successful– what could be improved– how to incorporate the successes and improvements in future

sprints

• This is an excellent opportunity for the team to get better and better after each sprint

17


Thanks

The lifecycle of an agile sprint

Technology

Transcript of The lifecycle of an agile sprint