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

Compare with Current View Page History

Version 1 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:

  • Reporting exceptions: point of scrum is to see if we are on track in our burndown chart, are we keeping in line with our estimates, 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

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?
  • 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