From MozillaWiki
Jump to: navigation, search

Firefox Desktop Iterative Development


The Iterative Development Model implemented for Firefox Desktop aims to accomplish six key objectives:

  • Transparent - Who is working on what, when, and why.
  • Predictable and Repeatable - Know what to expect from the process.
  • Inclusive - Include all key participants (Eng, UX, QA, Security, Product) and stakeholders in the process.
  • Clear Direction and Decision Making - Know what we should do and who makes the call.
  • Clear and Stable Priorities - Be clear on what is most important for each iterative cycle.
  • Innovative - Provide flexibility to engage in experimental and original projects.

Iteration 40.2 Performance

Note: Next update on Tuesday May 12 following the conclusion of Iteration 40.3

Iteration Production Goal

  • Team surpassed the IT 40.2 production goal of 182 points and completed 211 points.
  • The production goal for IT 40.3 is 114 points.
    • Note: Iteration production goal has been lowered as 7 individuals have moved to the FX Search Team.


Release Production Goal

  • Given the 211 points completed in IT 40.2 the team is currently ahead by 19 points in achieving the Release 40 production goal of 478 points.
    • Note: Release production goal has been lowered as 7 individuals have moved to the FX Search Team.


Velocity Range

  • Team achieved a median velocity of 159 points in IT 40.2 with a 90% likelihood the actual points completed in IT 40.3 will fall between 54 and 180.
    • Note: Forecast velocity range has been lowered as 7 individuals have moved to the FX Search Team.


Completion Rate

  • 116% of IT 40.2 point target completed which exceeded the 'success' range.


  • 80% of Release 40 point target completed to date.


Completed Work

Product Backlog

All work related to the ongoing development and maintenance of the Firefox Desktop Product are collected and prioritized in the Product Backlog. The goals of the Product Backlog are to:

  • Enable work to be prioritized so that the team is always working on the most important features.
  • Support continual planning as the product emerges so the plan matches reality.
  • Improve forecasts so that the stakeholders make the best decisions about the direction of the product.

The Product Backlog is maintained by the Senior Management team (Chad, Gavin, Madhava) to ensure new priorities are available for each Sprint Planning meeting.

Product Backlog: View Bugzilla


Note: Next update on Tuesday May 12 following the conclusion of Iteration 40.3

The Iteration Backlog is a collection of priority work the team has selected to work on in a two-week iteration.

Current Iteration - 40.3

Next Iteration - 41.1

  • Duration: Tuesday May 12 - Monday May 25

Upcoming Iterations

Release plan when each Firefox version goes to Central, Aurora, Beta, & Release: View Rapid Release Schedule

Firefox 41 Release

  • Iteration 41.2: Tuesday May 26 - Monday June 8
  • Iteration 41.3: Tuesday June 9 - Monday June 29
    • Note: IT 41.3 is a 3-week iteration.

Firefox 42 Release

  • Iteration 42.1: Tuesday June 30 - Monday July 13
  • Iteration 42.2: Tuesday July 14 - Monday July 27
  • Iteration 42.3: Tuesday July 28 - Monday August 10



Sprint Planning Meeting

Meeting Day of week Pacific Time Eastern Time Central European Time Time zone conversions
"Morning" Tuesdays 8:00AM - 9:00AM 11:00AM - 12:00PM 5:00PM - 6:00PM AWMY
"Afternoon" Tuesdays 4:00PM - 5:00PM 7:00PM - 8:00PM 1:00AM - 2:00AM AWMY

Iteration Performance Reports

Note: Next update on Tuesday May 12 following the conclusion of Iteration 40.3

Contribute to Firefox Desktop

Good First Bugs

These are tagged as [good first bug] in a bug's Whiteboard field. The challenge of a "good first bug" is only peripherally about the bug itself. The focus, for a new contributor, should be on getting your development environment set up and learning how to navigate Mozilla's contribution process. There are some excellent documents on MDN to help you get started, and the #introduction IRC channel exists just to help people getting started as contributors.

Good Next Bugs

Marked as [good next bug] on the whiteboard, these are a the next level up, where the challenge of the bug is actually fixing the bug. There are four parts to a well-described Good Next Bug: a willing mentor, a clear initial description of the problem, clear expectations on the part of the both the mentor and contributor, and a cooperative working relationship as the bug is resolved.

Diamond Bugs

Marked as [diamond] on the whiteboard, this label doesn't speak to a bug's difficulty, but rather speaks to its importance. Diamond bugs are bugs that have been brought up as important bugs in engineering's various priority-triage processes but aren't assigned to an engineer by the end of the triage process.