Firefox/Iterative Hello Development

Firefox Desktop Iterative Development

• Iteration 37.1 = 11/25 - 12/15, 37.2 = 12/16 - 12/29, 37.3 = 12/30 - 1/12 (added extra week at start of 37.1 for work week)
• Iteration 38.1 = 1/13 - 1/26, 38.2 = 1/27 - 2/9, 38.3 = 2/10 - 2/23 (Extended Support Release)

Objectives

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.

Iterations

Note: Next update on Tuesday February 9th following the conclusion of Iteration 38.2

The Iteration Backlog is a collection of Work that the team has committed to implement, test and deliver in a two-week iteration.

Current Iteration - 38.2

• Firefox Release 38 Goal:
  • Fx38 goal is to break down Screen Sharing and look at what can be implemented in the near term. Pref-off version of screen sharing (loop.screenshare.enabled), with the Windows only sharing expected early Feb. Tab sharing and Active Tab changing preparation work continues. Work on potential demos for MWC will take ~25% of development resources. Continuing to reduce tech-debt that has been accumulating over several iterations of quick feature additions is still a priority, especially to aid in QA coverage to avoid regressions as new features are added.
  • Time sensitive UI Tour bugs are requiring 1-2 developers focus during this iteration (not on Hello)

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Upcoming Iterations

Firefox 38 Release

• Iteration 38.1: Tuesday January 13 - Monday January 26
• Iteration 38.2: Tuesday January 27 - Monday February 9
• Iteration 38.3: Tuesday February 10 - Monday February 23

Firefox 37 Release

• Iteration 37.1: Tuesday Dec 2 - Monday Dec 15 (week added to 36.3)

Iteration - 38.1 Performance

• Firefox Release 38 Goal:
  • Sharing prototyped, Sharing issues identified / bugs broken down, Mobile Android demo evaluation, Include new TokBox SDK (included patches for Constraint impacts), progress made on CSS improvements.

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Iteration 37.3 Performance

Note: Next update on Tuesday January 13 following the conclusion of Iteration 37.3 (iteration included New Years). At the conclusion of Iteration 37.3:

• Firefox Release 37 Goal:
  • Fx37 goal is to reduce tech-debt that has been accumulating over several iterations of quick feature additions. However, focus in 37.3 should focus on the highest impact tech-debt bugs.

• Iteration 37.3 - Completed Work:

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

Iteration 37.2 Performance

Iteration 37.2 included Christmas - with 2 days of company holiday and many full week vacations. At the conclusion of Iteration 37.2:

• Velocity Range:
  • 22 bugs closed, 48 points.

• Firefox Release 37 Goal:
  • Fx37 goal is to reduce tech-debt that has been accumulating over several iterations of quick feature additions. However, focus in 37.3 should focus on the highest impact tech-debt bugs.

• Iteration 37.2 - Completed Work:

No results.

0 Total; 0 Open (0%); 0 Resolved (0%); 0 Verified (0%);

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 continually maintained by the Hello Management team to ensure new priorities are available for each Sprint Planning meeting.

• Priorities follow the Firefox Desktop Standard:
  • 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: As priority buckets start to have a large amount of bugs in them, the Rank field can be used to call attention to higher or lower rank and provide a way to sort easily in bugzilla. To have some rhyme/reason to the order - Rank should relate to Priority. The "Ranking" 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 "Parking Lot" area

Product Backlog:

• View Bugzilla for 38, tech-debt filtered out
• Tech-debt bugs priority based on etherpad discussion - though if you want one that's lower priority but impacting you - grab it
• untriaged bugs
• Trello Board

Backlog Triage

Triage Guidelines

• Bugs can be entered under Loop Client or Loop :: General at any point. By default they are set to "---" which means we will triage to a bucket at least every other week.
• If there is a bug that should be considered for taking ASAP - you can mark Blocking-Loop at "backlog ?"
  • Before it can be "backlog ?" 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

Triage Backlog

• View Bugzilla for untriaged

Adding Bugs to Triage

• Open a bug under Product "Loop", Component "General" or "Client"
• The Blocking-Loop flag is defaulted to "---", which will go into our list of bugs to Triage next
• Hello team reviews for inclusion into a release backlog every 2 weeks
• Backlogs for current releases are triaged more frequently.

Definition of Done

• The Definition of Done ensures a potentially shippable product increment is released at the conclusion of a release cycle.

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

Roles and Responsibilities

Due to the cross-team nature of this project - please follow the link to the central location for Roles and Responsibilities for Hello, webRTC, partner teams, and external partners

Communication

General

• Team Mailing list: Firefox/dev-media
• Team IRC Channel: #loop

Sprint Planning/Review and Status Meeting

Meeting	Day of week	Pacific Time	Eastern Time	Central European Time	Time zone conversions
"Daily Stand-up"	Monday, Tuesday, Wednesday, Thursday	8:00AM - 8:30AM	11:00AM - 11:30PM	5:00PM - 5:30PM	AWMY
"Retrospective"	Fridays	8:00AM - 9:00AM	11:00AM - 12:00PM	5:00PM - 6:00PM	AWMY

• Duration: 1 hour
• Vidyo Room: "webRTC-Apps"

Iteration Performance Reports

Note: Next update on Tuesday January 13 following the conclusion of Iteration 37.3

• View Current Report - Iteration 37.2: Tuesday December 9 - Monday December 22
• View Report Archive

Contribute to Hello Development

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. We are working on better documentation to help you get started with Hello (expect an update Q1 2015), and the #introduction IRC channel exists just to help people getting started as contributors.

• Hello Backlog Good First Bugs - View in Bugzilla