Versions Compared

Old Version 5

changes.mady.by.user Robin Colodzin

Saved on

compared with

New Version Current

changes.mady.by.user Cassandra Boell

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Corrected links that should have been relative instead of absolute.

Thalia Team Roles and Overview of Process 

SPRINT CYCLE - 6 weeks

  • Design: 1 Week
    • Sprint Planning happens at the beginning of this week
      • Available the thursday 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, and first . 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 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 Friday of this phase.
  • Product Release
    • Assuming we are on schedule, actual release would occur the tuesday of 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.

...

  • 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