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. The tasks needed to complete those features are captured in a list called the Sprint Backlog.
Artifacts
The team maintains a few artifacts to keep track of work.
Product Backlog
Available at: Bugzilla
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 MDN Product Backlog 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
Available at: Scrumbugs
At each Sprint Planning meeting, the development team decides what features it should complete in the upcoming Sprint. The individual tasks that are needed to complete those features are captured in a list called the Sprint Backlog. A different Sprint Backlog is created for each Sprint.
Organization
Tasks in the Sprint Backlog can sometimes become very broad, making the work more intimidating and more difficult to track. To avoid this, the team uses a few different criteria to break them down.
In general, the team breaks tasks down to be as small as is reasonable. For example, a task for implementing user login might be broken further into tasks like "Design interface for user login" and "Talk to Tim about how he implemented user login". The team also uses research tasks whenever possible. For example, when building a 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.
The team sometimes needs to coordinate with IT to complete a feature. When this happens, the feature is broken down by responsibility, with at least one task for the team to complete and at least one task for IT to complete. The tasks are written to be independent, so that the team can mark its tasks as complete even if the IT tasks are progressing more slowly. If more work is needed from the team after IT finishes its tasks, new tasks are open for the team.
The team pays special attention to breaking work down when a feature goes a long time without being merged into the MDN source code repository. When this happens, the work is broken down into one or more back-end tasks and one or more front-end tasks. As back-end tasks are implemented, they are merged without the corresponding front-end tasks. If there is more than one front-end task, the team uses Django Waffle flags during implementation to ensure that the front-end is not accessible until all of the tasks are complete. When all of the front-end tasks have been implemented, the Waffle flag is enabled to make the entire front-end available. Waffle flags can also be used to make incomplete parts of the front-end available to special users for testing.
Sprint Burndown Charts
Available at: Scrumbugs (shown on each Sprint's page)
The team uses a Sprint Burndown Chart during each Sprint to measure progress. A Sprint Burndown Chart lists amount of work on the y-axis and time on the x-axis, so that the trend line gradually moves toward the bottom right of the chart as work as completed.
Velocity
Available at: Google Docs
To estimate how much work can be completed in each Sprint, the team measures its development speed or Velocity. Velocity is measured in story points, a unitless value of development effort.
Status Reports
Available at: Standups
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 Scrum Master.
Meetings
Planning and Retrospective Meeting
The team meets at the beginning of each Sprint for a Planning and Retrospective Meeting. The meeting is broken 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 Scrum Master 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. Tasks needed to complete these features are captured in the Sprint 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 average 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 Velocity and cause bumps in Sprint Burndown Charts.
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
During each Sprint, the team works on the tasks that they added to the Sprint Backlog. A developer can work on any task that is not already assigned to someone. When he begins working on a task, he assigns it to himself. If he later decides that he does not want to work on the task, he removes the assignment so that someone else can work on it.
Handling development annoyances
The team occasionally encounters minor annoyances that affect their development work, such as receiving an overwhelming amount of error report emails. These problems are usually not serious on their own, but they can become more serious as they pile up. To manage this, each team member opens a Bugzilla bug with the keyword [dev-papercut] in the Status Whiteboard. At each planning meeting, the team considers a list of ignored papercuts when building the Sprint Backlog.
PTO
Team members notify the Scrum Master when they file PTO, so that he can help the team prepare accordingly.
Updating the MDN
Throughout the Sprint, the team occasionally pushes new changes to our production server. The team does this about once per week, usually on Tuesdays or Thursdays. Pushes on Monday and Friday are avoided.