MDN/Development/Process

The MDN development team follows the Scrum development framework to manage its work.

Overview

The team works in short development periods called Sprints. Each Sprint starts with a Sprint Planning meeting and ends two weeks later.

At each Sprint Planning Meeting, the team decides on a subset of features important to the MDN and commits to completing them before the two weeks end. This subset of features is captured in a list called the Sprint Backlog.

Artifacts

The team maintains a few artifacts to keep track of work.

Product Backlog

The Product Backlog is a large list of features that the team plans to implement. The Product Backlog is prioritized by a combination of thoughts from the development team, feedback from users, and strategic planning.

The team maintains its Product Backlog on Bugzilla. It is currently very large and somewhat difficult to understand, but the team plans to reorganize it soon to make it more understandable to outsiders.

Sprint Backlogs

At each Sprint Planning meeting, the development team decides what features it should complete in the upcoming Sprint based on the priorities reflected in the Product Backlog. The individual tasks that are needed to complete those features are captured in a list called the Sprint Backlog. A different Sprint Backlog is used for every Sprint.

The team maintains its [Sprint Backlogs] on Scrumbugs.

Sprint Burndown Chart

Organization

Features in the Sprint Backlog can sometimes become very broad. To avoid this, the team breaks features down into smaller tasks whenever possible. For example, a feature for user login might be broken down into tasks like "Design interface for user login" and "Talk to Tim about how he implemented user login". Breaking features up in this way makes them less intimidating and helps the team track its progress at a more granular level.

The team pays special attention to breaking features into smaller tasks when a feature becomes blocked. In general, the longer a feature goes without completion, the more it is broken down.

The team finds research tasks to be especially valuable. For example, when starting the user user login feature, the team might create a task like "Research: What services can we use to power login?". The team discusses the question and shares decisions in an associated Bugzilla bug.

Status reports

The team tracks its progress throughout each Sprint. Each team member shares a status update occasionally as important work is completed. If a member of the team is having a hard time making progress on a task, he or she can add the tag #blocked to his status report to request help from the MDN project manager.

The team records its status reports with a service called Standups.

Meetings

Planning and Retrospective Meeting

The team meets at the beginning of each Sprint for a Planning and Retrospective Meeting. The meeting is broken down into two parts.

Retrospective

In the first part of the meeting, the team discusses aspects of its process that have been working well and aspects of the process that could use improvement.

All thoughts shared in the Retrospective are reflected on this page. The MDN project manager treats this page like a Developer Bill of Rights, and works to ensure that the policies written here are enforced.

Planning

In the second part of the meeting, the team decides what features it should complete in the upcoming Sprint based on the priorities reflected in the Product Backlog. The team aims for variety in the features it chooses so that everyone can find something interesting to work on. The team plans to complete about two-thirds of the work it normally completes as reflected in its Velocity. The remaining one-third of work is left open for other features that developers choose based on their interests. These features are not added to the Sprint Backlog because doing so would complicate our Velocity and cause bumps in our Sprint Burndown chart.

After building the Sprint Backlog, the team plays Planning Poker to discuss the tasks in more detail and estimate how long it will take to complete each. If the team realizes that it has taken on too much or too little work, it adds or removes features from the Sprint Backlog accordingly.

Working

Assignment

Between the start of the Sprint and the end of the Sprint, the development team works on the features that they added to the Sprint Backlog. When a developer knows that he will be working on a particular feature, he assigns that feature to himself. When he knows that he will no longer work on it, he updates the feature to be unassigned so that someone else can begin working on it.

Handling development annoyances

Occasionally, the team runs into minor annoyances that affect their development work, such as an error that causes an overwhelming amount of email. These problems are usually not much of a problem on their own, but they can pile up over time. To handle this, anyone affected by these issues should open a bug with the keyword [dev-papercut] in the status whiteboard. The team will watch a list of ignored papercuts to make sure they don't pile up.

Updating the MDN

During the sprint, we occasionally add our new features to the MDN by pushing code to our production server. We push about once per week (usually on Tuesdays or Thursdays) and avoid pushing on Mondays and Fridays.