Firefox/Metro: Difference between revisions
| Line 13: | Line 13: | ||
<p> </p> | <p> </p> | ||
== | ==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.
| 30C-29A-28B Release Cycle |
|---|
Central 30
Bugzilla query errorArray ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 429 [1] => Unknown Error ) ) 1
Bugzilla query errorArray ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 429 [1] => Unknown Error ) ) 1
Bugzilla query errorArray ( [type] => error [message] => http-bad-status [params] => Array ( [0] => 429 [1] => Unknown Error ) ) 1 |
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
- Mailing list: Metro List
- IRC Channel: #windev
- Intranet: View Metro Page
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
- Iteration #23: Mon 1/20/14 - Fri 1/31/14 - View Performance Report
- Previous Reports - View Archive
People
| Role | Contacts | |
|---|---|---|
| Project Champion |
| |
| Program/Project Management Oversight |
| |
| Program Management |
| |
| Product Manager |
| |
| UX/Design |
| |
| Dedicated Engineering |
| |
| Graphics Team Support |
| |
| Localization |
| |
| QA |
| |
| Services Integration |
| |
| Privacy |
| |
| Release Management |
| |
| Marketing |
| |
| Legal |
| |
| Feedback |
|
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
- Metro Preview Release - View Release Proposal
- Metro Test Day - View Test Plan
- Mozmill Automated Testing: View Bug List
- Developer documentation, build instructions: Firefox/Windows 8 Integration
- Metro Work Week I: View First Work Week Event
- Metro Work Week II: View May 13 - May 17 Work Week Event
- Metro Work Week III: View January 6 - January 10 Work Week Event
- Asa's curated list of Non-sucky Windows 8 touch devices
- Archive - Development Summary: View Performance Statistics
- Blockers: View Queries