Engagement/MDN Durable Team/Processes

From MozillaWiki
Jump to: navigation, search

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 Outreach 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

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:

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 (or Epic) 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 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 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

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 Sprint Goals 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:

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.)

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.

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.

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 a task moves into the Review/Test column, 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.
  • 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 meet in a regular Standup meeting (typically twice a week, split by functional area).

In addition, the MDN team holds a Mid-sprint review on the second Wednesday 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. Due to time limitations, the team's demo does not cover all work during the sprint, but rather a few highlights.

The demo template should be created at the beginning of the sprint, so that team members can add to it as User Stories are completed. This can become a record of all outcomes from the sprint, which is then pared down for the sprint demo.

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.

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

  • What worked well?
  • What didn't work?
  • What steps will we take to improve?
  • How did the adjustments we decided on in the last retrospective go?

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

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

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