Engagement/MDN Durable Team/Processes
MDN Durable Team Processes
This page documents the processes used by the MDN Durable Team to help stakeholders, including volunteer contributors, to understand them. Many terms used here are linked to their definition in the team's agile glossary.
Proposing Work
Anyone may propose User Stories or Epics which describe work that may be done by the team.
- Team members can create User Stories in the Backlog in Taiga, and Epics as Taiga issues.
- Other stakeholders can contact the Product Owner (Kadir Topal) to propose User Stories and Epics.
Tools
Connecting Epics and User Stories
An Epic is a task or project which is too large in scope to be completed in a single sprint (currently 12 business days), so it must be broken down into multiple User Stories. Taiga does not explicitly support Epics, so the MDN team represents them as a type of "issue". Epic issues are linked to their user stories, and the user stories are tagged with the issue ID of their epic (for example, "epic 211"). For the mechanics of doing this in Taiga, see Connecting Epics and User Stories in the Taiga wiki.
Prioritizing Work
The product owner and other team members collaborate to prioritize proposed User Stories and Epics, and place them in the MDN Roadmap, based on when (if ever) they are expected to be worked on. Prioritization is done once per quarter. Priorities are driven by several factors, including:
- Mozilla software development timelines and releases
- Web standardization milestones
- Marketing initiatives
- IT infrastructure requirements and deadlines
Entries in the roadmap are linked to items in the Taiga backlog, which is the canonical repository of User Stories and Epics.
Tools
Triaging Requests
In addition to Epics and User Stories driven by organizational priorities as described above, requests for work to be done by the MDN durable team also arrive in the form of Bugzilla "bugs", in several forms:
- Requests for documentation changes (product="Developer Documentation")
- Mozilla product issues with the "dev-doc-needed" keyword set
- Requests for changes to the MDN platform (product="Mozilla Developer Network")
The process for triaging the first two types of requests is documented on MDN.
Bugs with "dev-doc-needed" are grouped based on the Firefox version in which the relevant code will be released. A User Story is created to address these "dev-doc-needed bugs" (often shortened to "DDN bugs" or even "DDNs") for each Firefox version, and is scheduled in a Sprint in order to be ready for the release date of Firefox Developer Edition with that version.
The third category of requests is triaged in a weekly "Bug Swat" meeting. See MDN Bug Triage Guidelines for details. See the MDN/Meetings page for details about triage meetings, and the Public MDN Events calendar for their schedule.
The outcome of triaging MDN platform issues is usually either "right now" or "someday". Emergency work ("right now") may be started immediately, and tracked as "other" tasks not contributing to a user story. Bugs in current work may be added as new tasks to existing user stories. Other work will be deferred, either as user stories in future sprints or deferred indefinitely. Leaving a bug open is rarely a commitment to fix the bug.
Tools
Planning Sprints
Selection of User Stories to be worked on during a Sprint happens in the week before the start of a new Sprint. Durable team members in the content and development areas work separately to select and flesh out the User Stories in each area, and place them in the Task Board for that sprint. The groups also review the Tasks for each User Story, to ensure that they can be done in one Sprint, and are complete enough to ensure that the Acceptance Criteria will be met. The whole team convenes for a Sprint Planning Meeting (usually on Thursday), to review and refine all the selected stories for the sprint. The team's committed User Stories will be shared with the broader Marketing team.
Tools
- Taiga backlog
- MDN Roadmap
- Task board for the Sprint; each one has a unique URL within Taiga.*
- Kanban board in Taiga
User Story Lifecycle
In addition to the Backlog, the MDN team uses the Kanban board in Taiga to track the status of User Stories in the planning process. The team represents the lifecycle of user stories with the following columns:
- Draft
- The user story is proposed, but incomplete.
- New
- The author has added Acceptance Criteria and Tasks; it is ready for review by the team.
- Ready
- The team accepts the user story as complete; it is ready to be prioritized and pushed into a sprint by the Product Owner.
- In Progress
- The user story has been committed for a Sprint, and at least one task is the In Progress task state.
- Ready for Test
- All tasks have been completed; it is ready for review of the Acceptance Criteria and Definition of Done.
- Done
- The Acceptance Criteria and Definition of Done have been met.
- Archived
- User stories that have been abandoned in Ready or In Progress with a comment explaining why they were abandoned (?? and those that were Done in a previous quarter ??).
- User stories that are abandoned in the Draft or New states are deleted from Taiga.
Managing Work
The ideal progression of a Sprint is that team members claim tasks, work on each of them until they are all done, and as a result, all the Acceptance Criteria of all the User Stories selected for the sprint are satisfied. Of course, life in the real world never runs perfectly, and the processes of a Sprint are designed to accommodate the bumps, blockages, and shifts that naturally happen. User Stories may sometimes move back to earlier stages if something unexpected happens, for example.
Tools
- Task board for the Sprint; each one has a unique URL within Taiga.*
Task Workflow
Tasks in a Task Board can be in one of the following states, typically in order (left to right in the columns of the board):
- New
- Planned, not being worked on at the moment
- In Progress
- Currently being worked on
- Ready for Test
- Completed, needs test or review
- Closed
- Completed and tested or reviewed
- Needs Info
- ?? Purpose is not clear
The following practices govern the handling of tasks:
- Each task that is not New should have an assigned owner.
- Each team member should minimize the number of tasks they have in In Progress at any given time, preferably to one task (but not zero unless on PTO).
- If a progress on a task is blocked by a dependency external to the team, set it as "Blocked", with an explanation; mention the blocker in the next Standup meeting.
- If a team member suspends work on a task without being blocked, move it back to the New state; make sure that comments on the task reflect the state of work completed so far, so that it can be picked up by someone else if needed.
- When a task moves into the Ready for Test state, find a specific other person to test or review the work; if needed, ask for a volunteer during the next Standup meeting. Asking "anyone" to do it means no one will do it.
- When a work product requires review by someone outside the team, create a separate task for managing the review, to avoid having completion of the main task be blocked by external factors.
- Use the "Unassigned tasks" swimlane for tasks that are not part of a User Story, but are necessary during the sprint and take up significant time of a team member.
Tracking progress
During the 12 work days of a Sprint, team members meet in a daily Standup meeting. For the MDN team, the discussion is driven by the order of tasks on the Task Board in the In Progress or Ready for Test columns (vs. "around the room" order).
In addition, the MDN team holds a Mid-sprint check-in on the second Tuesday of the sprint.
Sharing Outcomes
The Marketing-wide Sprint Review is typically held on the Wednesday of the third week of a Sprint cycle. In preparation, the MDN team holds a demo planning meeting on the third Monday, to review the accomplishments expected by the end of the Sprint, and agree on what the team will present in the Sprint Review. Team members add demo items or accomplishments into a template shared by the Scrum Master, which then becomes the demo packet that the team presents.
While the Product Owner leads the demo for the MDN team, teams members are welcome and encouraged to participate in the demo (while staying within the team's allotted 10 minutes).
Tools
- Google Slides
Improving Processes
At the conclusion of a Sprint, the team holds a Retrospective to reflect on the team's processes and habits, in order to find ways to improve or strengthen them. This meeting is limited to core team members, to facilitate frank discussion.
Marketing Durable Teams hold their Retrospectives on the third Wednesday of the sprint cycle, in most cases following the Sprint Review meeting. The MDN team holds theirs on that Wednesday, but prior to the Sprint Review, to accommodate the schedules of team members in Europe.
If the team decides to change processes that are documented in this article, then this article will be updated to reflect the change.
Tools
- Google Docs
- This wiki page
Communicating About Processes With Community And Other Stakeholders
The plans, activities, and outcomes of the MDN team's processes are of interest to a variety of stakeholders, most especially members of MDN's volunteer community.
The following practices will ensure that information is available to stakeholders as they need it, and is delivered to them at appropriate times.
- The MDN Taiga project is set as a "public project".
- The MDN roadmap and other related planning and outcome documents are publicly visible, by being linked from the MDN Durable Team's wiki page, and set with access "anyone with the link can view".
- The User Stories planned for each Sprint are announced on the MDN stakeholder mailing list, once they have been decided upon. Volunteers are encouraged to share their plans for MDN-related work as part of the thread.
- The work accomplished during a Sprint is shared on the MDN stakeholder mailing list, along with a link to the MDN team's "demo package" (note that the Marketing-wide Sprint Demo meeting is not public, because some durable teams may share confidential information).
- MDN Durable Team meetings (except Retrospectives) are public, and are marked in the Public MDN Events calendar, along with video conference connection information for video meetings.
- Team members are encouraged to seek help from volunteers for day-to-day tasks and reviews of work, by posting on the dev-mdc mailing list for content-related work, or the dev-mdn mailing list for web development work, and by discussing their work in MDN Community Meetings.