Skip to content
This repository has been archived by the owner on Jan 12, 2023. It is now read-only.

Sprint Process

Jump to bottom
Barbara Bermes edited this page Jun 28, 2018 · 30 revisions

Focus follows a 2-week sprint cycle with 6-week milestone releases. Dot-releases with bugfixes are released every two weeks. Our upcoming train schedule is here.

Issue naming and labels

Labels

Priority labels are based on the Bugzilla triage process and set during triage to determine when they'll be worked on:

Other labels:

  • addressed: Label for excluding items from triage. Should be used for [meta] items.

Issue Prefixes

  • [meta]: larger issues that need to be broken down, into a [breakdown] issue and issues for its smaller parts. This should include a checklist of all the issues (including the [breakdown] issue).

    These do NOT get a P* label, but should be in a milestone.

  • [breakdown]: issue to track the work of breaking down a larger bug

Triage - Weekly

  • (Link) Assign priority labels (P1, P2, ...) to bugs without priority labels or the addressed label
  • (Link) Ensure all P1 labels are assigned a milestone
  • (Link) Ensure all P2 labels are assigned a milestone

Weekly Bug management (alternating)

Sprint planning

Deciding what goes into a sprint, promote P2 issues to P1. After every release, this meeting is for deciding what goes into the upcoming milestone - add issues to the milestone and set them as P2.

Backlog grooming

Handling Triage overflow, adding to the contributor bug lists, looking at milestone lists.

Monthly Roadmap Planning

Plan and prioritize features for upcoming milestones - an update will be emailed out.

Plan and faciliate workweeks release schedule trying to work with things without proper training too much observing

Issue/Feature Process Flow

Open Issue

  • Issue is created by anybody
  • Is triaged, prioritized and has a milestone assigned
  • Issue includes enough information (follows template) that allows team members to estimate, understand the scope, user benefit, the what, and acceptance criteria

Ready for UX

  • When UX picks up issue, assign themselves to the issue
  • UX to provide mocks, attach to Github issue
  • Once UX is done, ready for eng, UX resource to unassign themselves, and use "ready for eng breakdown" label

** Ready for Eng**

  • Eng should only pick up issues that are ready for Eng and assigned to a sprint/milestone (not Backlog)

** Eng done **

  • Issue is eng done only if PR was submitted AND PR was reviewed
  • PR is closed but not issue
  • Issue will be assigned by eng to product manager (PM assigns it to other stakeholders where appropriate )

** Stakeholder review **

  • During sprints: Once PR is closed, the next day Nightly should have the changes and stakeholders can verify
  • During sprint review: everyone can review, comment
  • Once stakeholders are happy with result, PM assign "ready for QA" label and

Ready for QA

  • QA to watch for issues with "ready for QA" label AND in current sprint or major milestone
  • QA to assign the ticket they are currently working on to themselves
  • Once QA verified and completed issue, un-assign themselves from issue
  • Closes issue

Done

  • Issue is closed, no assignees and assigned sprint or major milestone
Clone this wiki locally