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.

• 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

• Scrumaster will drive the meeting, using the burndown chart. Purpose is to simply assess if we are on track: were our estimates correct or do we need to adjust 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.

WEEKLY TRIAGE

• QA should review all issues in the Triage queue before the meeting.
  • Note: Suggest developers wait and review Triage list right before the meeting or save time and just listen at the meeting.
• QA should run the Triage meeting.
• QA person should take notes; it's helpful to have a printed issues list.
• Triage meeting should run as:
  • QA person reads the issue number, the title and a brief description of the problem if needed - just enough info until the issue is understood.
  • Discuss if issue is related to another issue, a dupe, ask questions, request additional testing if needed, etc.
  • Team should:
    • Understand the issue to make sure change makes sense.
    • Think about possible ramifications of the requested change.
    • Make sure noted bug issue is really a bug (and not expected behavior).
  • Make issue decisions:
    • To be part of the current Sprint or which bucket it gets added to?
    • Assign resource.
    • If additional testing is needed, the issue could be reviewed again at the next Triage meeting or decided now.
• QA should should update Triage issues soon after the meeting.
  • Assign resource, Fix Version bucket, etc.
  • Include any relevant notes, link issue, etc.
  • Updates should include a comment to detail what's being changed, i.e.: Changing to Robin, Codfish as per Triage meeting 12/21/07.

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