SPRINT CYCLE – 6 weeks
- Design: 1 Week
- Sprint Planning happens at the beginning of this week
- Available the thursday BEFORE sprint planning, Product Owner will produce Theme for sprint, and prioritized list of issues for review
- Design meetings for any changes/new features that involve redesign. Only the key stakeholders for the given issue need attend. Out of that meeting should come a spec that QA can then use to write test plans from.
- Sprint Planning happens at the beginning of this week
- Feature Development: 2 weeks
- QA works on test plans for the upcoming functionality during this phase
- End of these 2 weeks is FEATURE FREEZE, and first release to QA
- No triage during the first week; should have triage the thursday of the second week
- Bug Backlog: 1 Week
- Bug triage weekly
- End of this week there should be another release to QA. Optionally there could be additional releases during the week.
- QA Phase: 2 weeks
- Bug triage weekly, or more if QA sees a need (not daily)
- Iterative releases to QA, decided upon by communication between dev and QA
- Towards end of cycle, QA gives recommendation of go or not go, and list of blocking issues that must be fixed in order to release.
- Communicate with customers about upcoming release.
- Product owner produces document for the next sprint the last friday of this phase.
- Product Release
- Assuming we are on schedule, actual release would occur the tuesday of the Design Week for the next sprint.
Scrum:
SCRUM
- Scrumaster will drive the meeting, using the burndown chart. Purpose is to simply assess Reporting exceptions: point of scrum is to see if we are on track in our burndown chart, are we keeping in line with : were our estimates , correct or do we need to adjust ; should be much shorter than its been
- What have you done = are you on track?
- Do you know what you have to do next?
- Impediments/dependencies
- them? are we on schedule with our due dates on tasks? Are there impediments that need to be addressed?
- This will require developers having estimates, and due dates in their tasks
- Are there any issues relevant to the whole team, or red flags that need to be raised?
- Scrum should be brief, probably closer to 15 minutes than a half hour.
ROLES:
ROLES:
Project Manager:
- Tracking status
- "The accountability piece": main artifact is the Burn-down chart
- Red flags (ie: people are going beyond what they estimated, totals add up to more time than is allotted, etc) should be raised to Janet
- Coordinate Biz issues
- Include PM tasks in the chart, with estimates and dates
- Collect information off-line, not in meetings
Product Owner – responsible for vision/priorities:
- Roadmap: higher level timeframe
- Themes for each sprint: put this out to group before sprint planning
- Takes first pass through feature/bug queue before sprint planning to organize/prioritize in light of larger roadmap (business value)
- Primary artifact is the product backlog, prioritizing
Team Manager:
- Resource management
- Performance
Developers:
- Estimates of tasks
- Reporting exceptions in the scrum: task is taking longer than is expected, etc
- Manage own bug queue
- Do feature work, then bugs – we need to assign these in appropriate size chunks, so this is possible within a given sprint
QA:
- Owns JIRA
- First pass at new bugs, assign:
- Component and developer
- Severity
- Priority
- Does this needed to be added to this round of changes? If so, raise it with team, in triage. If it seems really urgent, and a potentially large issue, might raise it in scrum as a red flag.
- Developers can pushback as needed, disagree with priority, severity, assignment
- Triage: mainly during QA phase, not during feature work; responsible for raising red flags, if there are issues that need to be addressed immediately/with greater urgency
- QA decides when final release is ok to go to prod
Customer Support:
- First response
- Customer messaging
- Customer Advocate
- In communication with "Product Owner" about customer needs, priorities as they come up