MDN/Development/ProcessNext

Version: 0.2

Purpose

The MDN team uses Kanban to manage its work. The team feels that Kanban better fits its style of working and provides benefits that align with current goals.

This document describes an early, minimum viable Kanban process. The team will use and refine this process over time. When the process reaches a certain level of maturity, the team will request feedback more widely and use that feedback to formalize a process that all parties are pleased with.

Overview

Users and other stakeholders can request changes to the MDN at any time using the Mozilla Developer Network Feedback form. The MDN Project Manager occasionally reviews these requests and, based on stakeholder feedback, decides which ones the team should complete. For each of these, a new Kanban card is created and added to a phase called Selected. Over time, these cards move out of Selected and through three other phases in order: Design, Development, and Review & QA.

The team uses Kanbanery and Bugzilla to manage this process. Each Kanbanery card refers to the Bugzilla bug (created by the Mozilla Developer Network Feedback form) that describes the original request. The team uses the bug to collaborate as progress is being made. For example, the team might use the bug to share mock-ups or hold technical discussions.

When a phase is completed (see the section Phases), the card is marked as Ready in Kanbanery. At any point, a team member working in the next phase can pull a Ready card into his phase and begin working on it. Phases are not skipped when a card is moved. If a phase is not required for a given card, the group responsible for that phase simply marks the card as Ready immediately.

All requests go through this process. The team can elect to work on any requests that interest them, but they are first approved by the Project Manager (to ensure they balance with other priorities) and go through the same phases (to ensure quality).

Phases

Selected

One card is added to this phase for each change that should be completed soon.

Design

The team collaborates on a detailed design for the change. The card is marked as Ready after a designated person (or group) signs off on this design.

Development

The development team implements the change. The card is marked as Ready after a pull request is submitted for the change.

Review & QA

The development team completes a code review and a spot check. As needed, additional quality assurance and acceptance from the person (or group) who signed off on the design can be done here. The card is marked as Ready when the team is confident that the change works as designed.

Card Management

Work Types

Cards are grouped into three different work types.

• Bug
• New feature
• Change to existing feature

Size

Everything on the Kanban board should be roughly equal in size. This makes work less intimidating and easier to handle. John works with the team to find large high-priority items in the MDN product backlog and break them down to be roughly equal in size.

Assignment

Every card is assigned to someone in Kanbanery, with the exception of cards in the Selected phase. Assignment is self-directed. The person assigned to a card is not necessarily the only person working on it, but the person ultimately responsible for ensuring the Ready criteria are met.

If a person is no longer working on a card, he should change the assignee to "nobody". Anyone else who comes along should feel free to pick up "nobody" tasks and work on them themselves.

Deadlines

The Deadline feature of Kanbanery is used to highlight changes that have hard deadlines. The team and Project Manager pay special attention to these cards to ensure they are completed on time.

Subtasks

Team members are encouraged, but not required, to use the Subtask feature of Kanbanery to break their work into more manageable pieces. Subtasks are only used to track work in the current phase.

Blockers

If a card cannot move to the next phase until some work is done, that work is marked as a Blocker in Kanbanery. The Blocker might be another card, the address of a WebOps bug or just a written description of the impediment.

Work in Progress Limits

Important to note that these describe active work being done. Columns are not queues. If only 3 cards can be actively worked on in a column, the WIP limit should be 3, or 4 to allow for some flexibility. There should not be a backlog of things going on in a column -- just things being actively done.

• Selected: 3
• Design: 3
• Development: 5
• Review: 3

Planning and Retrospective meeting

The development team, Product Manager, Project Manager and interested users meet every two weeks to discuss process improvements and review the state of development.

Tracking Progress

Visual Overview

The best indication of progress is the visual overview provided by the team kanban board.

Written Overview

The team communicates more detailed progress using Standup.

Notifications

The team publishes several RSS feeds that interested parties can subscribe to for notifications about progress.

• All team progress
• Cards that have passed Ready criteria and can be pulled into a new phase
• Blockers that have been resolved
• Cards that are being actively designed
• Cards that have moved into a new phase
• Changes that have been released