You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

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
  • No labels