Firefox/IterativeDevelopment
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 31.3 Performance
Note: Next update on Tuesday May13 following the conclusion of Iteration 32.1
At the conclusion of Iteration 31.3:
- Team completed 143 points across 45 bugs.
- Points completed decreased by 48 from the previous iteration.
- Bugs completed decreased by 3 from the previous iteration.
- Team carried over 193 points across 32 bugs to the next iteration.
- Point carry over increased by 22 from the previous iteration.
- Bug carry over increased by 7 from the previous iteration.
- Team accomplished a 43% close rate during the iteration.
- Closure rate decreased by 19% from the previous iteration.
- 45 bugs completed during the iteration have been verified by QA.
- 15 points across 5 resolved bugs could not be verified by the conclusion of the iteration and carried over to the next.
- Velocity Range: Median velocity of 88 points with a 90% likelihood the actual velocity will fall between 57 and 191.
- Production Forecast: 90% likelihood that 171 to 573 points of work, with a median value of 264, can be completed over the three iterations of the 32 release cycle.
44 Total; 0 Open (0%); 0 Resolved (0%); 44 Verified (100%);
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
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
Adding Bugs to Triage
- Click on 'set flags'
- Set 'firefox-backlog' flag to '?'
- Desktop Triage Team will review for inclusion in the Product Backlog
Iterations
Note: Next update on Tuesday April 29 following the conclusion of Iteration 31.3
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 - 31.3: Tue 04/15/14 - Mon 04/28/14
44 Total; 0 Open (0%); 0 Resolved (0%); 44 Verified (100%);
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
- Mean Incremental Progress
Tested and Verified
Note: Full Desktop Firefox release testing workflow and process - View Detailed Walkthrough
- 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
|
||
Product Manager
|
||
UX/Design
|
||
Dedicated Engineering
|
||
QA
|
||
| Release Management | ||
| Marketing |
Communication
General
- Team Mailing list: Firefox/firefox-dev
- Team IRC Channel: #fx-team
Backlog Refinement Meeting
- Time: Thursdays - 12:00 - 1:00 (PST), 3:00 - 4:00 (EST)
- Duration: 1 hour
- Vidyo Room: "Firefox"
- Iteration Backlog: View Priority List
Sprint Planning/Review and Status Meeting
- "Europe" meeting: Time: Tuesdays - 8:00AM - 9:00AM Pacific
- "Eastern" meeting: Time: Tuesdays - 9:30AM - 10:30AM Pacific, 12:30PM - 1:30PM Eastern
- "Pacific" meeting: Time: Tuesdays - 12:30PM - 1:30PM Pacific
- 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: 1 hour
- 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 29 following the conclusion of Iteration 31.3
- Iteration 31.2 - Tue 04/01/14 - Mon 04/14/14: View Current Report
- View Report Archive