The lifecycle of an agile sprint
Download as PPTX, PDF7 likes4,450 views
The document outlines the lifecycle of an agile sprint, detailing the roles of participants such as the product manager, product owner, and scrum master. It describes the processes from sprint planning, user story creation, testing, and daily updates, to the end-of-sprint review and retrospective meetings aimed at continuous improvement. Emphasis is placed on collaboration, flexibility, and achieving a 'done-done' status for user stories before releasing them.
The lifecycle of an agile sprint
- 1. www.optier.com The lifecycle of an agile sprint Step-by-step guidelines January 15, 2014 v. 3a © 2012 OpTier. All rights reserved.
- 2. www.optier.com 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
- 3. www.optier.com Participants in the agile process • PM (Product Manager)
- 4. www.optier.com Participants in the agile process • PO (Product Owner)
- 5. www.optier.com Participants in the agile process • Scrum Master
- 6. www.optier.com Participants in the agile process • The Team
- 7. www.optier.com 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 cart So 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
- 9. www.optier.com 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
- 10. www.optier.com 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
- 11. www.optier.com 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
- 12. www.optier.com 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
- 13. www.optier.com 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
- 14. www.optier.com When is a story really DONE? • • • • • • (This is called Done-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 14
- 15. www.optier.com 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
- 16. www.optier.com 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
- 17. www.optier.com 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
Editor's Notes
- #2: Insert the date, version number and copyright line on the cover page only.