MDN/Development/ProcessNext
Version: 0.2
Purpose
The MDN team plans to adopt 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 and 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 stakeholders 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 decides which ones the team should complete based user and stakeholder feedback. 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 five other phases in order: Design, Development, Review & QA and Archive.
The team uses Kanbanery and Bugzilla to manage this process. Each Kanbanery card references the Bugzilla bug (created by the Mozilla Developer Network Feedback form) that describes the original request. During development, the bug is used to collaborate and share progress. For example, the team might use the bug to share mock-ups or hold technical discussions.
When the Ready criteria are met for a phase (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 occasionally skipped. For example, a card that describes a technical change that has no direct impact on design can skip the Design phase. The group responsible for the phase being skipped should make that determination.
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
Backlog
MDN product backlog. All things that we could be done.
Selected
Activity
Things that we should do soon. One card is added to this phase for each change that should be completed. Cards are roughly prioritized by the Project Manager.
Design
Activity
The team iterates on a visual design and a written description of behavior.
Ready criteria
- A Photoshop document (.psd) or very detailed mock-up has been shared
- A written description of behavior has been shared
- A designated person (or group of people) has signed off on these assets
Development
Activity
The team implements the change.
Ready criteria
- A pull request for the change has been submitted
Review & QA
Activity
The team completes a code review, a spot check, acceptance testing and (as needed) additional quality assurance.
Ready criteria
- The code has been reviewed by a developer
- The change has been spot-checked by a developer
- The change has been approved by the same person (or group of people) who approved the design
- The change has been merged, and can be pushed at any time
Archive
Activity
The team pushes the change to staging and production. The card is moved into the Released phase and the corresponding bug is marked as RESOLVED:FIXED.
Card Management
Work Types
Cards are grouped into three different work types.
- Bug
- New feature
- Change to existing feature
Size
Every Selected item is estimated on a t-shirt scale, with the choices X-Small, Small, Medium, Large, and X-Large. The team collects information about how long each size of request usually takes to complete, and uses this information to communicate expected dates of delivery to stakeholders.
Changes that are especially large are broken down so that stakeholders can see progress and share feedback within a reasonable amount of time.
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
- 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.