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 and developers can use to implement code 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. The release engineer will deliver first release to QA with a release note stating details of what new features are included in this release.  
  • No triage during the first week; should have triage the thursday of the second week

• Bug Backlog: 1 Week
  • Bug triage weekly
  • At the end of this cycle, there is a developer code freeze. This means that after this point, only fixes to bugs related to the development work in this sprint can be addressed. Code should be branched (see SVN Guide for details).
  • End of this week there should be another release to QA. Th release note should include a list of bugs fixed in the new release candidate. 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)
  • Developers will be fixing major bugs as they come in, bug fixes will be checked into the release branch.
  • Iterative releases to QA, decided upon by communication between dev and QA. Release notes will accompany any release to QA.
  • The final release candidate should be stable by the wednesday before the release to production.
  • 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 or Wednesday of the Design Week for the next sprint. The code should be tagged in the release process. Please refer to guide on how to release thalia .

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
• Release Engineer:
  • Releases to QA
  • produce QA release notes
  • branches and tags code
  • Coordinate with isda-ops for release date (open RT ticket)
  • prepare the final release candidate for isda-ops
• 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
    

Useful links:
svn guide
jira guide
thalia release process
thalia release communication