Skip to content
This repository has been archived by the owner on Apr 17, 2021. It is now read-only.

Planning Process

Jump to bottom
liuche edited this page Jun 26, 2019 · 7 revisions

Sprint Routines

  • Standup: [whole team] what I did, what I'm doing, what I need/blocked on. team discussion (internal Mozilla doc)
  • Triage: [whole team] classify bug/chore/feature from GitHub, urgent or not? So PO can promote to sprint
  • Grooming: [product owner + lead + optional] leads decide what's important for the sprint and break it out more
  • Pre-Sprint Technical Risk: [lead/rotating] after Grooming, 1-2 people go through the items prioritized to go into sprint and hash out requirement details (or add questions to be resolved and @mentions)
  • Review: [whole team] demos and explanations of what was completed, ready for release?
  • Retrospective: [whole team] what went well, learned, puzzled? what actions should we consider? (internal Mozilla doc)
  • Planning: [whole team] tickets are ready to go, estimates provided, eng advocates, commit to next sprint

See also: Release Process for every sprint

GitHub Issues

Types

Issues are how we track work to be considered and completed. We have three primary types of work:

  • feature: building something new or improving something for the product or user
  • bug: fixing something that exists but is not working as designed or intended
  • chore: doing some task or work to unblock or complete work not described in the above two, task to make tooling, work for the team, task to do
    • we also use "Investigation" issues to do the preparation work to then split out and create the remaining corresponding feature/bug/chore work for bigger projects (ex: Investigate the approach to build X thing)

When a new issue is created in GitHub, an issue template prompts for the expected information to be collected and automatically applies the label.

Urgency

  • release blocker: a new release or version should not be sent to the public until this is fixed (which gates fixes or features from going live)
  • urgent: this is time-sensitive because there is a window of opportunity, something that needs to happen first so other work can happen later, etc.

Estimation

Using the corresponding size label applied to the issue indicates the following (include review time):

  • S: 1 pt = 1 day = 6 - 8 hours
  • M: 3 pts = 2-3 days = 12 - 18 hours
  • L: 5 pts = a week = ~30 hours, needs to be broken down

…beyond that is too big.. make it an epic or break it down perhaps?

Priorities

  • P1: high frequency or impact or both, tied to business need, etc.
  • P2: some impact or some frequency
  • P3: low impact or frequency or both
  • P5: certainly worth consider but we likely won't ever

Kanban / Project Board

We use a private kanban board, each quarter (internal to Mozilla) to track the team's planned, in progress, and completed work.

  • To be triaged: Everything explicitly added to the Project starts here and pops onto the top of the stack. Items we’ve agreed are to be done get labeled and moved to the Backlog.

  • Backlog: Items that are prioritized and considered “stretch” goals to work on during the current sprint, likely to appear in the next one or definitely expected to be in a future one within the quarter.

  • Sprint Backlog: Items we’ve agreed we have everything we need to begin engineering work (requirements, designs, answers) and will commit to doing during the current sprint.

  • Blocked: Items we do not have everything needed to begin engineering or production work, waiting on another cross-functional team or requirement or task to be complete. We use additional labels to help explain what is blocking:

    • needs ux = needs UX designs or input, Issue is also assigned to the UX point of contact to be explicit
    • needs product = needs a product decision or input
    • strings needed = need the strings extracted for this feature to get localized properly

  • In Progress: Work has started and typically a Pull Request has been created that “fixes issue #”, linking the two items together. Testing, UX and code reviews happen here.

  • Done: Once the issue (and PR) is closed, then the cards automatically move into this Done column. They’re archived after the sprint review and QA acceptance (see Release Process).

  • QA Verified: the QA team explicitly tested and confirmed the item from the Done column and moved it here during the sprint to indicate it was accepted. Not all Done items will be tested or moved here.

Development Process

  1. Claim an issue by assigning it to yourself, if not obvious, and consider moving it to “In Progress”
  2. Create a Pull Request
  3. There is no step 3...

See also: CONTRIBUTING and CONTRIBUTING_code

Clone this wiki locally