Firefox/IterativeDevelopment/ProductionModel

Production Model

Feature Preparation

Each individual feature is outlined in a Story format as follows:

1. As a <user> I want to <function> so that I can <business value>.
2. Acceptance Criteria (AC): <Steps necessary for this Story to succeed>.
3. Notes: <Any additional information pertinent for the developer>.

Product Backlog

The Work (features, defects and changes) 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 the Senior Management team (Chad, Gavin, Madhava) to prioritize the work so that the team is always working on the most important features, defects and changes.
• Support continual planning as the product emerges so the plan matches reality.
• Improve forecasts so that the stakeholders make the best decisions about the project goals.

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 Refinement

The Product Backlog Refinement Meeting is intended to prepare the Product Backlog for the next Sprint Planning Meeting.

In the Backlog Refinement Meeting, the Senior Management team (Chad, Gavin, Madhava) will:

• Triage all newly submitted Work (features, defects and changes) currently in the Product Backlog.
• Split and clarify large work into smaller and more manageable components.
• Prioritize the Backlog Work into a force-ranked list of desired functionality.

Step 1: Triage Identification

• The Project Manager will mark all newly submitted features, defects and changes with the [triage] whiteboard tag and will block bug 950073 (Product Backlog).
• No bugs marked as [triage] will be considered for selection in an iteration.

Step 2: Bug Triage

• At the meeting, the Project Manager will run the [triage] query to display the list of all newly submitted triage work.
• Team Leads will review each item to determine if it warrants inclusion in the Product Backlog or not.
  • Approved items will have the [triage] whiteboard tag removed.
    • Items identified as new defects will be marked with the [defect] whiteboard tag.
    • Items identified as new features will be marked with the [feature] whiteboard tag.
    • Items identified as new work related to existing, or previous, features will be marked with the [work] whiteboard tag.
  • Bugs identified as Invalid, Wontfix, Duplicate, Works For Me and Incomplete will be marked as such, have the [triage] whiteboard tag removed and will no longer block bug 950073 (Product Backlog).
  • Items requiring further investigation will keep the [triage] whiteboard tag for review at the next meeting and continue blocking bug 950073 (Product Backlog).

Step 3: Feature Breakdown

• At the meeting, the Project Manager will run the [feature] query to display the list of all newly submitted features.
• Team Leads will review each one to determine which require breaking down into small components.
• Team Leads will identify, where possible, senior staff that will be assigned to create the work dependencies related to the development of the feature.

Step 4: Prioritization

• At the meeting, Project Manager will run the query to display the list of all work not containing a [triage] whiteboard tag and export the list.
• The Team Leads will review the list and rank order the bugs for use at the Sprint Planning Meeting.
• The Project Manager will take the exported list and rank order the work in Bugzilla.
  • The Priority Ranking is in effect between Product Refinement Meetings.
  • A new Priority List will be generated each week.

Sprint Planning

At the beginning of each Sprint, the entire team participates in a Sprint Planning Meeting to determine which Product Backlog Items will be converted to a working product during the Sprint. The Senior Management team (Chad, Gavin, Madhava) is responsible for declaring which items are the most important to the Firefox Desktop product. The team (development, design and QA) is responsible for selecting the amount of work they feel they can implement without accruing technical debt.

Backlog Review

The Backlog Review and Selection is focussed on presenting the prioritized Backlog (most important functionality at the top to the least at the bottom, according to business value) to the team.

The Senior Management (Chad, Gavin, Madhava) team will be ready to consult and give guidance on any questions the team has about the prioritized list. They will provide the team with details regarding the higher priority items and articulate the value associated with the top items on the Product Backlog.

The key question for this part of the meeting is, “What needs to be built first?"

Work Breakdown

Following the review, the team will identify the highest priority Work (Features, Defects and Changes) which are too large and must be split into multiple smaller, easier-to-estimate work items.

These individual work items will be converted into Bugs which will block the completion of the whole Feature. The team will provide point estimates to each of the individual work items (bugs) instead of the entire Feature.

The key question for this part of the meeting is, “How do we build it?"

Sprint Backlog

Following the work breakdown, the team 'pulls' work from the Product Backlog to the Sprint Backlog. This work represents the final commitment from the team of the work they want to accomplish during the Iteration cycle.

The key question for this part of the meeting is, “How much work will we, the team, commit to do?"

Point Estimation

All work in the Sprint Backlog is initially sized into three large point buckets: Easy (Points 1, 2, 3), Medium (Points 5, 8) and Difficult (Point 13).

The team starts with the Easy Bucket and picks the smallest one (everybody agrees that it is the smallest and easiest) and size it as 2. The first work item that is sized with "2" will be the benchmark and every other work item in the Easy Bucket will be relative to this one. They will take another work item from the Easy size bucket, and estimate it relative to the first one.

From here, all work items in the other point buckets will be estimated using this "triangulation" method.

Sprint Execution

TBD

Definition of Done

Discussion: DOD

Quality Assurance

Discussion: Quality Assurance

Iteration Conclusion

Review

Each new Iteration Planning Meeting begins with a review of the previously completed Iteration.

In preparation for the meeting, the Product Manager will review the working product increment and the commitments made for the Iteration. The Product Manager will provide the team with feedback on which items are considered done according to the Definition of Done.

• Incomplete items are returned to the Product Backlog and ranked according to the revised priorities as candidates for future Iterations.
• New Product Backlog Items created from the review feedback will be prioritized by the Senior Management team as candidates for future Iterations.

Reporting

The Project Manager will prepare and distribute a Performance Report for the previously completed Iteration.

• The Performance Report for the first four Iterations will include basic data:
  • List of Sprint Backlog Items Completed
  • Total Points Completed
  • Total Sprint Backlog Items Completed

• As more Iterations are completed the Performance Report will be extended to include data for:
  • Fifth Iteration Cycle
    • Actual Velocity
    • Velocity Range
    • Forecast Production Capacity (median and range)

• • Tenth Iteration Cycle
    • Defect Rates
    • Blocked Time
    • Cycle Time
    • Work Time
    • Efficiency

Discussion: [TBD]

Example: Example Status Report