Program Management/ProjectPlanTemplate/Firefoxdesktop

From MozillaWiki
Jump to: navigation, search

Why are we doing this?

The goals of the Product Backlog and dynamic Planning are to:

  • Simplify prioritization & planning so the team is always working on the most important features.
  • Improve visibility into clearer priorities to make good decisions quicker and call out risks early. Enables balancing relative priorities and trade-offs.

Here is a slide deck to talk to new teams (usually Eng Mgr and PM)

Key Bugzilla Queries

  • Key Queries should include:
    • Ranked Backlog limited to team focus
      • Work with eng mgr and PM to determine how bugs for the "team" target bugs are marked up. Could be product::component, whiteboard tag, or flag
      • Define how work that has been triaged into the Backlog is represented.
    • Untriaged Backlog limited to team focus
      • Bugs in your teams focus area that have not been added to the backlog or ranked
    • Complete view of work for members of the team - if they are on multiple projects
  • example

Triage Guidelines

The Product Backlog is continually maintained by the Team to ensure new priorities are available for each Sprint

  • provides the Team: dev, UX, PM, EPM, and also Product Line owners visibility into the work and enables good conversations around trade-offs, feature priority, and rough timing.
  • helps align expectations
  • if you don't see a field discussed below under your product::component, you can request adding it at a Product level or for a specific Component via bugzilla.mozilla.org::administration. You may need to request Rank and whatever Backlog flag you want to use.
    • when requesting exposing fields, you should create a group for the field to manage rights (and the list of people who should be in that group)
      • simpler to add people to group and give group access to multiple fields
      • naming convention is <team>-backlog-drivers. we have one for firefox-backlog-drivers and platform-backlog-drivers already.
      • everyone on team should have rights to the backlog flag you chose, and we've been giving everyone rights to Rank as well - though only EPM, PM, and Eng manager usually set it at Triage or before planning meeting (engineers usually don't want to manage the list - just provide info on priority)

A snapshot of a Backlog that uses some common triage guidelines looks like is below:

  • RANK enables view into the backlog of work priority
  • Theme enables quickly understanding what the focus of the work

Visuals for Triage

  • Priority works with Rank by gathering bugs into groupings that can then be ordered against similar "Priority" work. The creator of a bug or a triager may quickly set Priority and leave it for later to fit the bug above or below existing bugs in that Priority bucket using RANK.
    • RANK is discussed and re-adjusted at Planning meetings. This makes for quickly maintaining an accurate sort in bugzilla to view work.
    • Priorities using the Firefox Standard bucket guidelines:
      • Priority 1 - Blocker, must-fix before shipping.
      • Priority 2 - Major impact, considering severity × probability. Not a blocker for shipping.
      • Priority 3 - Average Bug. definitely a problem, but doesn't stop someone from using the product.
      • Priority 4 - Minor or polish bugs that are real issues (especially in aggregate) and annoying.
      • Priority 5 - Low-impact. something we'd fix, but mostly only bothers the discerning user. Little impact on usability.
  • RANK is used by the dev team to quickly see relative work priority and select "next bugs" (often at Planning Meetings or on-demand when needing next work)
    • Primarily set and updated during Triage
      • Reviewing 'THEME focuses in the sorted backlog for coming work with PM and UX before Planning meetings helps ensure alignment and that pre-work for coming bugs is ready.
    • It is not a blocker from taking new work that comes up. Dev simply marks that they've taken a bug and gives a priority and EPM will pull it into the Ranked backlog. This gives visibility to account for the full workload when Planning new focus work.
      • To keep rhyme/reason to the buzilla query sorting - RANK should relate to Priority. The RANK number does not need to be unique. Unless there is a reason to for a bug to be considered before (or after) others in the Priority bucket - default to mid-range value.
    • P1 Rank options=1-19, default 15
    • P2 Rank options=20-29, default 25
    • P3 Rank options=30-39, default 35
    • P4 Rank options=40-49, default 45
    • P5 Rank options=50-59, default 55
    • any that we don't think we can get to in the next 6 months should go in "backlog-" or "parking lot" area
  • Themes is a free form entry into the Whiteboard field, usually between brackets[].
    • Themes should reflect groups of work in major feature or work areas
    • Setting Themes make Planning meetings much more productive (for both choosing work and having discussion if it seems like the ordering isn't aligned with something)
    • There should be an ordered Theme list (usually in the wiki) that reflects at a high level how Themes relate.
      • PMs are the owners for setting the Theme order. As new work interjects above existing Themes in the list - PM & EPM can adjust external roadmap expectations (new work comes in - other work comes later).
    • Themes enable a quick dialog across the area Teams and the Product Line owners to make sure we are aligned.
    • Themes allow summaries of Iteration and Release focused for anyone to see. Here is an working example of using Themes on a Team sprint management wiki
  • Iteration should be updated when a bug is being worked on during a particular Sprint. This is set at the planning meeting, updated for bugs that were not completed, and if new bugs as taken during the Sprint the dev should set this flag.
    • Caveat: not all teams are using Iteration
  • A Backlog mark-up is used to track bugs that are approved for the Backlog "+". This gives a simple way to separate triaged bugs from untriaged bugs.
    • Adding to the Backlog means it has been intentionally triaged from a list of bugs or someone (dev, UX) with domain knowledge that had to create the bug filled out the fields to get it quickly into the Ranked backlog.
    • Firefox uses a custom flag called firefox-backlog (+,-).
    • Non-Firefox teams can add a flag under the Blocking flag for Backlog
      • Request adding a "<team name>+" option for your team and request right for your team to edit the Backlog flag. file bug under bugzilla.mozilla.org::administration.
        • Parking Lot, under the Backlog flag, is generic across teams - and can be used by multiple teams as their queries will differ, to mark bugs that aren't ready for Backlog or closing.
    • When the team needs to add a bug for known high priority work - have them set everything (including Backlog flag) except Rank. That way their bugs are quickly assimilated into the visible work.
    • If you don't see the blocking-flag option on your product - you can request it be added. (bugzilla.mozilla.org::administration don't forget to request full rights to it for everyone on the team)
    • If you span many, many components - the Tracking flags are on most components and you can request for a new one.


  • QE-Verify is a flag that developers should be setting on bugs they are working on. This is used for QE to filter which bugs they check
    • "+" means that QE should look at the bug and it can be verified with human eyes
    • "-" means QE should not look at
      • Typically goes with in-testsuite set to "+", to show testing via another method.

Quickly marking a bug that is taken

  • If a bug is taken out of the normal submit, triage, assign process - set the Priority and the backlog flag. If your team is using Iteration, then add that as well.
  • "Rank" can then be easily added and the work included in the Ranked Backlog, as a bug with no Rank but the other fields, will show up at the top of the query.
  • Also set the QE-Verify flag if it is visibly verifiable.
  • "Points" should be set when known (if nothing set - assumed a "1" or very small). Most relevant if taking a bigger bug so we know when bugs are large bits of work.

Filing a bug

  • Where bugs are filed vary by group - but if you have a wiki you should say under which product:: component bugs should be filed.
  • Triage is recommended at least bi-weekly for a 1/2 hour (weekly if more bugs). This will keep you on top of the work.
    • Before it can be triaged and given a Rank it should:
      • be in an actionable state
      • for defects, the problem is ready for Engineering or UX: diagnosis, measurement, design, or fixing
      • for feature requests or enhancements, it means that there's a clear problem statement or suggestion
      • has a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months

Definition of Start & Done

Start

  • It's possible not all these items need to be defined or agreed on by all members of the team, but the lack of these items should indicate red flags)
    • PRD's have been created
    • User stories created
    • UX created / reviewed
    • Above requirements are understood (including dependencies such as: access to staging, new hardware, skill set development etc)
    • Dev, QE and PM resources are mapped to intended goals
    • schedules create and agreed on
      • Shell put link to "Critical Path" excel google doc showing timing/work impact across releases.

Done

  • The Definition of Done ensures a potentially shippable product increment is released at the conclusion of a release cycle.
    • may differ by team - this is just an example

  • A potentially shippable product increment means compliance with the work's individual acceptance criteria and not the full story under development.

Development

Schedule

Release timing

Sprints (if team is using 2 week sprints)

Themes

  • These are the high level areas of focus to make sure Product, UX, and Engineering are aligned.
  • Many Themes are what we then break down into User Stories, though some are more work based groupings like "quality" or "tech-debt".
  • This is not a commitment to the next projects - just our scratch area of order of relative priority.
  • As new requests or needs come in - they are evaluated in where they fit in the relative list.

Example Theme list:

  • finishing Theme 1 (large change)
  • Theme 2: any time constraints/dependencies. [theme] or [meta] bug number link is ideal
  • Theme 3: quick why and bug number

Things we want to do - but parking lot until higher priorities are done:

  • Process Improvement: Theme
  • Other platform Investigation
  • Tech-debt: any time constraints/dependencies
  • Theme 4
  • Quality: description of areas
  • Theme 5

Risks

  • Risk 1 : ex: Roadmap goals for the release in November are too high for ____(dev, UX, PM?) resources by x amount (bugs? points? UX resources). likely will not make any features beyond x, y, z.
  • Risk 2 : ex: Dependency on a service that is not established/planned for from another team. Need help prioritizing if we should delay the feature in this project or raise the priority in the other team based on their existing backlog

Current

Here are sample wiki queries into bugzilla to start from to see if you can adapt to meet your needs depending on what level your team wants to see information.

Iteration Release#.Iteration - Uplift Date

  • Friendly summary of goals of iteration
  • Pipeline of work that has been pulled for this iteration and closed work - EXAMPLE

Past

Iteration Release#.Iteration - Uplift Date

  • Ideally these aren't just queries, but human readable so folks know what is coming in x release
  • Pipeline of work that has been completed and moving through Aurora and Beta to release - EXAMPLE


Project Introduction

  • Team Mailing list: ex: Firefox/dev-media or the general team mailing list (doesn't need to be project specific)
  • Team IRC Channel: ex: #loop or the general team channel (doesn't need to be project specific)
  • Summary of our plans for this year (links back to main page for the area - ex: platform or desktop have roll-up pages with very high level goals)
  • More detailed Roadmap, noting that the further out the more lose the targets are
  • Dependencies: feature, partner, resource, etc. - put links to other project pages.

Links to Current info

The Links wiki page is the central location for current focus, Roadmap, Metrics, UX, Marketing, tech-architecture, and more.

Roles and Responsibilities

The Contacts Page has the Roles and Responsibilities for this team, partner teams, and external partners involved in this project.

Meetings & Communications

Go to the Templates page for sample agenda's and invites to these meetings

Meeting Day of week Pacific Time Eastern Time Central European Time Vidyo Room Notes
"Planning" bi-weekly at the start of the iteration on ___ 8:00AM - 9:00AM 11:00AM - 12:00PM 5:00PM - 6:00PM webRTC-Apps https://etherpad.mozilla.org/templatenewteam etherpad]
"Stand-ups" Monday, Tuesday, Wednesday, Thursday 8:00AM - 8:30AM 11:00AM - 11:30PM 5:00PM - 5:30PM webRTC-Apps etherpad
"Retrospective" Friday 8:00AM - 9:00AM 11:00AM - 12:00PM 5:00PM - 6:00PM webRTC-Apps etherpad
  • Links to mailing list or all communication channels

EPM Reference

Project Health

IOS,Desktop Yellow Risk.png

  • (get central location for graphics from Erin)

Include clear, executive level summary that will be included at the [mana page overall view level:

  • for company goal x, we are in _____ state because ______. Please consider ______(propose fix or adjustment of goal).
  • for release goal for ______ , we are in _____ state because ______. Please consider ______(propose fix or adjustment of goal).

Status Reports

example from Jenn's

  • This is an area we want to dig into further - if each team could summarize what they know in a consumable format - then one person could give an up to date overview of the larger project as needed.

Bugzilla Agile fields

Several Fields have been added this year into bugzilla for Agile tracking that you may want to leverage:

  • Iteration: right now this has the 3 previous and future 2 week sprints for Firefox release schedule - shows iteration (40.1) and uplift date.
  • Points: Fibonacci series 1,2,3,5,8,13]
  • Rank: see Rank use description under Triage Guidelines
    • Rank will not show under your Product::Component unless you request it by filing a bug with "bugzilla.mozilla.org :: Administration". You need to give a list of acceptable editors (usually the folks that can triage).

Tools

  • area that needs more info
  • Aha - would love to get Romain's fantastic starter deck here and possibly time for him to go through with other team PM's.
  • Trello
  • https://waffle.io/mozilla/payments

Reading

Retrieved from "https://wiki.mozilla.org/index.php?title=Program_Management/ProjectPlanTemplate/Firefoxdesktop&oldid=1087736"