MDN/Development/Process

The MDN development team loosely follows Scrum to manage its work.

Overview

We work in two week periods called Sprints. A Sprint starts with a Sprint Planning Meeting (see the section Planning and retrospective meeting) and ends one day before the next Sprint Planning Meeting.

During each Sprint, we work on a subset of features (see the section [[MDN/Development/Process#Sprint_Backlogs|Sprint Backlogs) that we committed to in the Sprint Planning Meeting.

Documents

Product Backlog

Link: Product Backlog

The Product Backlog is a large list of features that we plan build, prioritized by a combination of thoughts from the development team, feedback from users, and strategic planning. Priorities are re-evaluated according to these criteria before each Sprint.

Our Product Backlog is very large and somewhat difficult to understand right now, but we are planning to reorganize it to make it more understandable to people outside of the development team.

Organization

At times, features in the Product Backlog can become broad and vague. To avoid this, John will break features into smaller actions when necessary. For example, he might open subtasks like "Create a mockup for this feature" or "Research how we should implement this portion of the feature."

Sprint Backlogs

Link: Sprint Backlogs

At each Sprint Planning Meeting, we consider the highest priority features on the product backlog and decide which ones we should complete during the upcoming Sprint. We capture these features in a list called the Sprint Backlog. Each Sprint has its own Sprint Backlog.

Status reports

Link: Status reports

We use a status reporting service called Standups to share our progress during a Sprint. We post status updates occasionally as important work is completed. If someone is having a hard time making progress on a task, he adds the #blocked tag to his status report so that John can help.

Meetings

Planning and Retrospective Meeting

We meet as a team once every two weeks for a Planning and Retrospective Meeting. This meeting is broken down into two parts.

Retrospective

During this part of the meeting, we discuss what about our process has been working well, and what about our process could use improvement. We update this page based on this discussion.

Planning

In the second part of the meeting, we build a new Sprint Backlog by looking at the Product Backlog and deciding which of the features we should complete in the upcoming Sprint. We plan for about two-thirds of the work that we normally complete in a Sprint, and leave the last third open for other features that developers choose based on their interests.

After building the Sprint Backlog, we play Planning Poker to estimate the work that we have committed to and to have more detailed discussions about how we will complete that work. If Planning Poker reveals that we not taken on the appropriate amount of work, we add or remove features to the Sprint Backlog accordingly.

Working

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.

Updating the MDN

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