A step-by-step checklist for how to manage your agile sprint. This presentation will point you to the right direction and mentions all the keywords you need to know when approaching the agile methodology.

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

8. www.optier.com
Feature
Feature
Feature
Feature
Feature
Feature
Feature
Feature
US
US
US
US

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

18. www.optier.com
Thanks