Firefox/Metro: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 13: Line 13:
<p> </p>
<p> </p>


==Status Update==
==Development Update==
<p> </p>
<p> </p>
'''Note:'''  Next update on Monday February 17 following the conclusion of Iteration 30C-29A-28B.1
'''Note:'''  Next update on Monday February 17 following the conclusion of Iteration 30C-29A-28B.1

Revision as of 00:29, 9 February 2014

Firefox for Windows 8 Touch

Production Summary

Note: Next update on Monday February 17 following the conclusion of Iteration 30C-29A-28B.1

At the conclusion of Iteration #23:

  • Points Completed: 76
  • Bugs Resolved: 30
  • Team Velocity: 59
  • Velocity Range: 47 - 68

Development Update

Note: Next update on Monday February 17 following the conclusion of Iteration 30C-29A-28B.1

  • At the conclusion of Iteration #23, given the historical velocity performance of 18,30,32,33,42,43,46,47,50,51,56,59,61,63,64,68,74,74,75,76,77,78,80, the Metro Team has a median velocity of 59.

  • At a median velocity of 59, there is a 90% likelihood that the actual velocity for upcoming iteration will fall between 47 and 68.

  • With 75 points worth of work selected for the current iteration, there is a 90% likelihood that between 7 - 28 points worth of work could carry over into the next iteration.
    • Note: The value of the work selection and range of point carryover is higher this iteration due to the full integration of point estimates from UX.

Product Backlog

All work related to the ongoing development and maintenance of the Firefox for Windows 8 Touch 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.

Product Backlog: View Bugzilla

Bugzilla query error

Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 429 [1] => Unknown Error ) ) 1

Release Plan

The Release Plan is a guideline that reflects expectations about which features from the Product Backlog will be implemented and when they are completed across multiple iterations for specific target releases. It also serves as a base to monitor progress with the ongoing development of the product. The Release Plan is not static and will be revisited and updated at the conclusion of each iteration.

Iteration Backlog

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: IT-30C-29A-28B.1 - Monday February 3 - Friday February 14

Bugzilla query error

Array ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 429 [1] => Unknown Error ) ) 1

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)

Communication

General

Iteration Planning/Status Meeting

  • Time: Mondays - 1:00 PM Pacific, 4:00 PM Eastern
  • Duration: 1 hour
  • Vidyo Room: "Marco Mucci"
  • Etherpad: View MoPad

Iteration Performance Reports

People

Role Contacts
Project Champion
  • Johnathan Nightingale (johnath@mozilla.com) (A,C,I)
Program/Project Management Oversight
  • Sheila Mooney (smooney@mozilla.com) (A,C,I)
Program Management
  • Marco Mucci (mmucci@mozilla.com) (R)
Product Manager
  • Chad Weiner (cweiner@mozilla.com) (A,C,I)
  • Karen Rudnitski (krudnitski@mozilla.com) (A,C,I)
UX/Design
  • Yuan Wang (yuan@mozilla.com) (R)
  • Michael Maslaney (mmaslaney@mozilla.com) (R)
Dedicated Engineering
  • Tim Abraldes (tabraldes@mozilla.com) (R)
  • Brian R. Bondy (bbondy@mozilla.com) (R)
  • Matt Brubeck (mbrubeck@mozilla.com) (R)
  • Sam Foster (sfoster@mozilla.com) (R)
  • Jim Mathies (jmathies@mozilla.com) (R)
  • Ally Naaktgeboren (ally@mozilla.com) (R)
  • Rodrigo Silveira (rsilveira@mozilla.com) (R)
  • Marina Samuel (msamuel@mozilla.com) (R)
  • Stephen Pohl (spohl@mozilla.com) (R)
Graphics Team Support
  • Manager - Milan Sreckovic (msreckovic@mozilla.com) (C,I)
  • Dev - Kartikaya Gupta (kats@mozilla.com) (R)
  • Dev - Botond Ballo (bballo@mozilla.com) (R)
Localization
  • Axel Hecht (axel@mozilla.com) (R)
QA
  • Juan Becerra (jbecerra@mozilla.com) (R)
Services Integration
  • Mike Connor (mconnor@mozilla.com) (I)
Privacy
  • Sid Stamm (sstamm@mozilla.com) (A,C,I)
Release Management
  • Bhavana Bajaj (bbajaj@mozilla.com) (C,I)
Marketing
  • Laura Forrest (lforrest@mozilla.com) (I)
Legal
  • Manager - Harvey Anderson (handerson@mozilla.com) (A,C,I)
  • James Murdock (jmurdock@mozilla.com) (A,C,I)
Feedback
  • Tyler Downer (tdowner@mozilla.com) (A,C,I)
  • Manager - Matt Grimes (mgrimes@mozilla.com) (I)

The letters following each name stand for:

  • R = Responsible for deliverable
  • A = Accountable for the final decision making on some aspect of the project
  • C = Needs to be consulted on key topics
  • I = Needs to be kept informed

References