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.

Assessing Product Opportunities

The MDN team uses an Opportunity Assessment Process to evaluate, rank, and flesh out proposed significant changes to the MDN product.

Prioritizing Work

At Mozilla, priorities are set using a framework of Objectives and Key Results (OKRs for short). Objectives are aspirational goals set annually, and Key Results are measurable targets set quarterly. The Epics and User Stories that track work in sprints typically define deliverables that are expected to enable reaching the quarterly Key Results.

Priorities are driven by several factors, including:

• Mozilla software development timelines and releases
• Web standardization milestones
• Developer Relations initiatives
• IT infrastructure requirements and deadlines

Quarterly Key Results are listed on the MDN Durable Team's wiki page. For many efforts, the team creates a Project document, linked from the wiki page. These documents summarize the purpose, success metrics, accountability matrix, and other key elements of the project.

Tools

• ZenHub browser extension
• ZenHub board for MDN
• Quarterly Key Results

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 "bugs" or issues, in several forms:

• Requests for documentation changes
• Mozilla product issues with the "dev-doc-needed" keyword set
• Requests for changes to the MDN platform (product="developer.mozilla.org")

For the first type of request, see the content issue triage process.

Bugs with "dev-doc-needed" are grouped based on the web platform feature they pertain to. A User Story (or Epic) is created to address these "dev-doc-needed bugs" (often shortened to "DDN bugs" or even "DDNs") for each web platform feature, and is scheduled in order to be ready when that feature is available in multiple browsers.

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 issues a priority ranging from P1 (highest) to P5 (lowest), with the following meanings:

• P1: Will be done by staff during the current or next sprint
• P2: Will be done by staff during the current quarter
• P3: Will be done by staff "eventually"
• P4: Not used
• P5: Valid issue that will not be done by staff; patches are welcome from volunteer contributors.

Leaving a bug open is rarely a commitment to fix the bug. P1 and P2 bugs are reviewed at the end/beginning of each quarter to determine if their priority is still valid.

It's a bit awkward to have some types of work represented as Bugzilla bugs, while the majority of MDN work is represented as GitHub issues. When a Bugzilla issue is planned to be worked on during a sprint, a GitHub issue should be created for it, containing a link to the Bugzilla issue. Use GitHub (and ZenHub) for estimation and status-tracking; use Bugzilla for discussion. Typically, DDN bugs for a given release and functional area of Firefox are grouped into single GitHub issues (e.g., JavaScript DDNs for Firefox 63). DDNs within a group should be estimated individually, and rolled up into an estimate for the group. DDNs that represent a significant chunk of work (e.g., new docs or major revisions) should be split out as separate GH issues from their group.

Emergency work can be started immediately and may pre-empt work that was previously planned for the sprint; in such a case, affected team members should confer with the product owner to decide what to do with other affected work.

Tools

• DocTracker spreadsheet

Planning Sprints

Selection of User Stories to be worked on during a Sprint happens in the week before the start of a new Sprint. A sprint is three weeks, with 12 working days and 3 planning days, with some adjustments for quarters and work weeks.

Brainstorming of user stories to be worked on happens in a planning scratchpad document (for example, this one from Q3 2018). Typically, user stories are categorized by the quarterly Key Results they support. However, a given Key Result might not have supporting user stories happening in any given sprint, and a sprint may contain miscellaneous user stories not connected to a Key Result. Based on this brainstorming, team members create or modify the corresponding user stories as issues in GitHub, and ensure they are ready to be placed in the Backlog in ZenHub. The team optionally identifies a Sprint Goal for Content and Development, which is an area of highest priority for the sub-team; team members are expected to contribute to or support the Sprint Goal foremost if possible. However, it is not required that each sub-team has a Sprint Goal for every sprint, or that team members must work on it, if doing so is not suited to their skill set.

Items placed the Backlog must have:

• Acceptance Criteria
• Size estimate (points)

The size estimate categories are based on the number of "ideal" days they are expected to take to complete; ideal days would be those devoted to working on the story, without meetings, email, or other interruptions. Values can be from 1 to 5; stories that need more than 5 days should be broken into smaller stories. (Fibonacci values are not used.)

The MDN team's Definition of Ready defines requirements that certain work types must meet in order to be considered ready to be worked on (and therefore able to scheduled into sprints).

This work can be done asynchronously, or during project- or team-specific planning meetings.

The whole team convenes for a final Sprint Planning Meeting (usually on Thursday), to review and refine all the selected stories for the sprint. The team should keep in mind the number of person-days available in the sprint (based on the number of days in the sprint, the number of people on the team, and the number of exceptions, such as holidays, PTO, travel, etc.). The total number of story points for the stories in the sprint should not exceed (and preferably be less than) the number of available person-days.

Note: User stories must have acceptance criteria and estimates by the time of the final sprint planning meeting in order to be accepted into a sprint.

User stories are given confidence ratings (High/Medium/Low), indicating how confident the team is that the user story can be completed during the sprint. The team also reviews 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.

GitHub milestones are used to represent sprints. For each sprint, a milestone is created with a deadline of the last day of the sprint.

If a user story from one sprint is moved to another sprint, it should have its milestone, size estimate, and confidence estimate updated to correspond to the new sprint, the remaining work, and the confidence in the context of the new sprint.

Tools

• ZenHub user story board
• Story board for the Sprint; filter the main ZenHub board based on the milestone that represents the sprint.

User Story Life Cycle

The team represents the life cycle of user stories with the following columns (a.k.a., "pipelines" in ZenHub parlance):

New Issues

The user story is proposed, but has not been reviewed.

Epics

The user story is an epic with sub-stories; epics are usually not assigned to milestones.

Not Ready

The story has been accepted to be worked on, but is missing components, such as Acceptance Criteria, size estimates or confidence estimates. The missing pieces may be called out by the tags: NeedsAC, NeedsTimeEst, or NeedsConf.

Backlog

The team accepts the user story as complete; it is ready to be added into a sprint by assigning a milestone to it. It must have acceptance criteria, time estimates to be added to the Backlog, and must also have confidence estimates to be added to a sprint.

In Progress

The user story has been committed for a Sprint, and work has started on it.

Review/Test

All tasks have been completed; it is ready for review by subject-matter experts (for content stories), or code review by a peer (for development stories).

Done

The work and reviews have been completed. It is ready for sign-off by the Product Owner or relevant team lead.

Closed

The Product Owner (or team lead) has signed off, based on the Acceptance Criteria and Definition of Done, and has closed the issue.

Icebox

The issue is valid, but is not going to be worked on by the core staff team. It might be picked up by a volunteer. Or, the issue is deferred, but the future sprint it will go in is not defined.

The following practices concern maintaining user story status:

• If a user story is blocked in such a way that it can't be completed during a sprint, it should be removed from the sprint milestone (with an explanatory comment).
• If a user story is in Done, but the product owner finds that the Acceptance Criteria and Definition of Done are not complete, it should be moved back to In Progress, and more tasks added that will enable it to reach completion. The Definition of Done for the MDN team is maintained in a Google document.

Managing Work

The ideal progression of a Sprint is that team members claim user stories, 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, or a user story might be deferred to a later sprint, due to a change in external circumstances, such as slippage of a feature's release.

The following practices govern the handling of user stories:

• Each user story that is in In Process should have an assigned owner. GitHub allows multiple people to be assigned to an issue.
• When an items moves into the Review/Test column, find a specific other person to test or review the work. Asking "anyone" to do it means no one will do it. For items that take a significant amount of time to review, the reviewer should be identified and the review time estimated and accounted for as part of sprint planning.
• 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.
• When a content user story is moved to Review/Test, it can be helpful to the reviewer to add a link to the completed or updated documents.

Tracking progress

During the 12 work days of a Sprint, team members need to communicate regularly about progress and obstacles. The MDN does this mostly asynchronously, using Status Hero. The sub-teams hold a synchronous Standup meeting on the first Wednesday of a sprint, and the whole team meets for a Mid-sprint review on the second Monday of the sprint.

Sharing Outcomes

A sprint demo meeting is held on the Thursday between sprints. Team members add demo items or accomplishments into a document that serves as an agenda for the meeting. Due to time limitations, the demo does not cover all work during the sprint, but rather a few highlights.

The team should consider whether any items shown or discussed in a sprint demo should be shared with the wider Emerging Technologies audience, at an upcoming monthly ET All-Hands meeting.

Tools

• Google documents

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.

The MDN durable team uses a slightly different structure for the retrospective discussion:

• How did the adjustments we decided on in the last retrospective go?
• What worked well?
• What should we change or stop doing?
• What steps will we take to improve?

Variations on this structure are possible, to avoid staleness. For some retrospectives, it may be helpful to focus on a specific aspect of the work, processes, or tooling used by the team.

If the team decides to change processes that are documented in this article, then this article will be updated to reflect the change.

Tools

• Trello
• 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.

• All MDN-related GitHub repos are public. Anyone can view the ZenHub board by installing the ZenHub extension in Firefox or Chrome
• 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 discussion forum, 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 discussion forum, along with a link to the MDN team's demo doc.
• 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 MDN discussion forum.
• Due to the distributed nature of the MDN team and community, asynchronous communication (email) is preferred over ad-hoc synchronous meetings. Whenever possible, hold discussions in public, such as on the MDN discussion forum.
• When meetings are needed (especially for planning and prioritization), invite all team members, using mandatory and optional attendee settings in Google Calendar to indicate who is required, vs. informed. If possible, add meetings to the MDN public calendar to enable community members to attend. Make sure there is a guest Vidyo link in the calendar event.
• Take and share notes of meetings to communicate decisions made, actions assigned, etc.