MDN/Development/ProcessNext
Version: 0.2-pre
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 satisfied 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 four other phases in order: Design, Development, and Review & QA, and Archive.
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 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 after it is pulled in.
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. Sometimes, additional quality assurance is completed and sign-off is requested from the person (or group) who signed off on the design. The card is marked as Ready when the team is confident that the change works as designed.
Archive
A card is moved to the Kanbanery Archive when the change it describes has been released.
Card Management
Work in Progress Limits
The team uses Work in Progress (WIP) limits to control the amount of work being done at a given time. A card is not pulled into a new phase if this limit has already been reached.
| Phase | WIP Limit |
|---|---|
| Selected | 3 |
| Design | 3 |
| Development | 5 |
| Review & QA | 3 |
Work Types
Cards are grouped into three different work types.
- Bug
- New feature
- Change to existing feature
Size
Cards are roughly equal in size. If a request seems particularly big, the MDN Project Manager works with the team to break it down.
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 that the card becomes Ready.
When a person is no longer working on a card, she changes the assignee to nobody. At any point, a team member can assign one of these cards to herself and begin working on it.
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
The team is strongly encouraged, but not required, to use the Subtask feature of Kanbanery to break work into more manageable pieces.
Blockers
If a card cannot move forward until some other work is done, that other work is marked as a Blocker in Kanbanery. The blocker might be another card, the address of a Bugzilla bug, or even just a written description of the impediment.
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 Kanbanery.
Written Overview
The team sometimes communicates more detailed progress using Standup.
Notifications
The team publishes several RSS feeds that interested parties can subscribe to for notifications about progress.