MDN/Development/ProcessNext
Version: 0.3
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: Research & Design, Development, Review & QA, and Released.
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 designs 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 fit 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.
Research & Design
The team investigates a technical solution to the change. The team also decides if a detailed design is needed before handing the work off to the development team, whether the development team should get started on it, or in the case of bigger features -- if the work should be done behind a feature flag so that we can iterate on the design over time. The card is marked as Ready after the team feels comfortable handing off the change to the development team for development.
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 team considers not only functionality but also security, performance, and other important factors during this phase. The card is marked as Ready when the team is confident that the change works as designed and meets other quality standards.
Released
The change has been released to the production server.
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 |
| Research & Design | 4 |
| 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 before work is started.
Break down before getting on the board. Breaking down is informal. If something is still in the backlog, prioritize it. Then, either put the whole thing into "Selected" or just a piece. If only a piece, the bug will stay in the backlog and the process can repeat.
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, another 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.
Meetings
Priority meeting
Just me and Ali. Over time, other stakeholder representatives will be invited.
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.
Working with contributors
add [mentor=openjck] to easy bugs I see
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 stakeholders can subscribe to for notifications about progress. Remember that information might change by the time you receive the notification. Always click through the notification or consult the board for the most up-to-date information.