Sprint Architecture
Length: 10 business days
Day 1
Dev:
QA:
Day 2:
Day 3:
Day 4:
Day 5:
Day 6:
Day 7:
Day 8:
Day 9:
Day 10:
Testing
Discussion with Grace - April 4
Bugs addressed during the sprint. Leave some space for bug testing during the sprint
10 business days
First 3 days:
Ad-hoc testing
UAT prep - documentation regarding the previous sprint
Users can test what was completed last sprint - Grace or Steve, do not need two team members
TGD team - QA team tests first, and then PO or user tests, and the user or PO marks it as done. User or PO testing does not need to be complete during the same sprint.
Issues to think about:
How to track modifications to backlog items. E.g. when testing, if something needs to be added, what should we do?
Test Cases
Questions:
What will the test cases be used for? (e.g. backlog testing, automated testing, future use)
How can we minimize the amount of work required to write a test case? E.g. focus on developing a specific feature per sprint, so test case writing can start on day 1 - ? Perhaps identify which backlog items will need test cases at the beginning of the sprint, so test case writing can start at the beginning?
Automated Testing
How can we implement?
How can we keep QA involved?
What is the outcome of implementation? E.g. less QA manual testing
Unit Testing
{Add short write-up, description}
Release Planning Architecture
2 month release schedule - Release Train
Total: 4 sprints
Sprint 1
Dev:
60% - New development
10% - Bug Fixes
20% - Tech debt
10% - Release activities
QA:
70% - Backlog item testing
20% - User testing - day 10? Either PO or QA?
10% - UAT prep
Sprint 2
Sprint 3
Dev:
QA:
50% - ACC environment testing
50% - UAT testing (with users) - Test environment?
Sprint 4
Dev:
50% - Release activities
?? % - Critical bug fixes?
?? - ??
Dev - Release Architecture Needed
Manual to automated - Jugraj is working with Henry on this
One click deployment
Patch fixes - how do we implement?
Anything else?