Firefox/IterativeDevelopment

From MozillaWiki
Jump to navigation Jump to search

Firefox Desktop Iterative Development

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, 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 30C-29A-28B.3 Performance

Note: Next update on Tuesday April 1 following the conclusion of Iteration 31C-30A-29B.1

At the conclusion of Iteration 30C-29A-28B.3:

  • Team completed 79 points across 17 bugs.
    • Points completed increased by 22 points from the previous iteration.
    • Bugs completed decreased by 9 bugs from the previous iteration.

  • Team carried over 111 points across 22 bugs to the next iteration.
    • Point carry over increased by 66 points from the previous iteration.
    • Bug carry over increased by 14 bugs from the previous iteration.

  • Team accomplished a 41% clores rate during the iteration.
    • Closure rate decreased by 27% from the previous iteration.

  • All 17 bugs completed during the iteration have been verified by QA.

  • Team Velocity: NA - Available following the completion of five iterations

  • Velocity Range: NA - Available following the completion of five iterations

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) at the Product Backlog Refinement Meeting to ensure new priorities are available for each Sprint Planning meeting.

Product Backlog: View Bugzilla

No results.

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

Backlog Triage

Triage Guidelines

These guidelines should help determine whether a bug should be included in the Firefox desktop team's backlog.

These are guidelines, not strict rules. Ultimately the decision rests on the judgement of the triage teams, and exceptions are possible. They should however be uncommon.

To be included in the Firefox desktop backlog, a bug 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
  • have a difficulty/user-impact ratio low enough that we can reasonably expect to spend time fixing the bug within the next 6 months
    • this is a judgement call, obviously, and so the triage teams will need to learn to make these decisions over time
  • be within the general area of ownership/responsibility of the Firefox team (engineering and UX)
    • this means e.g. platform bugs that are outside of our area of expertise/ownership should generally not be added to our backlog

Triage Backlog: View Bugzilla

No results.

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

Iterations

Note: Next update on Tuesday April 1 following the conclusion of Iteration 31C-30A-29B.1

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: 31C-30A-29B.1 - Tue 03/18/14 - Mon 03/31/14

No results.

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

Definition of Done

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

Potentially Shippable Guidelines:

  • Means Tested and Verified
  • Does Not Mean Cohesive

Tested and Verified

  • QA will be flagged to test work marked as 'Resolved' within the iteration.
  • Any defects found will 'Reopen' the work subject to testing.
  • If QA does not discover any defects the work will be marked as 'Verified'.
  • Only 'Verified' work will merge into a build at the conclusion of the release cycle.

Product Increment

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

Bugzilla

The following format is used to maintain consistency in how bugs are filed:

  • p= (point value assigned to the bug)
  • s= (the iteration the bug is being developed in)
  • r= (the target release of the bug under development)
  • [story] (collection of related bugs required for the completion of a feature)

Roles and Responsibilities

Role Contacts
Project Champion
Program/Project Management
  • Monitor team and project performance
  • Submit status report at conclusion of each Iteration
  • Organize and facilitate Triage and Planning meetings
  • Guide team through the practices and procedures of the project
  • Ensure team and project impediments are addressed
Product Manager
  • Define and document product features
  • Maintain Product Backlog, Feature Stories up-to-date and prioritized
  • Review Iteration Build Release
UX/Design
  • Self-organizing and self-managing; team determines how much work they can commit to from the Product Backlog during each Iteration Planning meeting
  • Deliver UX assets/work necessary to progress work in backlog
  • Responsible for attending Planning meetings
  • Report impediments to the Project Manager
  • Keep work item, Feature Story and Epic status up-to-date
Dedicated Engineering
  • Self-organizing and self-managing; team determines how much work they can commit to from the Product Backlog during each Iteration Planning meeting
  • Deliver build for every sprint consisting of work from sprint backlog
  • Responsible for attending Planning meetings
  • Report impediments to the Project Manager
  • Keep work item, Feature Story and Epic status up-to-date
QA
  • Create and execute test plans
  • Verify acceptance criteria
  • Responsible for attending Planning meetings
  • Report impediments to the Project Manager
Release Management
Marketing

Communication

General

Backlog Refinement Meeting

  • Time: Fridays - 12:00 - 2:00 (PST), 3:00 - 5:00 (EST)
  • Duration: 2 hour(s)
  • Vidyo Room: "Firefox"
  • Iteration Backlog: View Priority List

Sprint Planning/Review and Status Meeting

  • Time: Tuesdays - 8:00 AM - 10:00 AM Pacific, 11:00 AM - 1:00 PM Eastern
    • First Tuesday focussed on Sprint Planning/Review.
    • Second Tuesday focussed on Team Update.
    • Note: The day/time for this meeting is for the initial process launch. When the entire team has been integrated there will be three meeting time slots (European/Eastern/Pacific) on Tuesday.
  • Duration: 2 hour(s)
  • Vidyo Room: "Firefox"
  • Iteration Backlog: View Priority List
  • Process Launch Team Members:
    • Chad Weiner - Product
    • Bryan Clark - Product
    • Javaun Moradi - Product
    • Tracy Walker - QA
    • Juan Becerra - QA
    • Anthony Hughes - QA
    • Jenn Chaulk - Project
    • Lawrence Mandel - Project
    • Marco Mucci - Project
    • Madhava Enros - UX
    • Sevaan Franks - UX
    • Jennifer Morrow - UX
    • Gavin Sharp - ENG
    • Steven MacLeod - ENG
    • Felipe Gomes - ENG
    • Drew Willcoxon - ENG
    • Paolo Amadini - ENG
    • Marco Bonardo - ENG
    • Asaf Romano - ENG
    • Neil Deakin - ENG
    • Florian Queze - ENG

Iteration Performance Reports

Note: Next update on Tuesday April 1 following the conclusion of Iteration 31C-30A-29B.1

Retrieved from "https://wiki.mozilla.org/index.php?title=Firefox/IterativeDevelopment&oldid=958613"