Engagement/MDN Durable Team/Processes
- 1 MDN Durable Team Processes
- 1.1 Proposing and Assessing Opportunities
- 1.2 Prioritizing Work
- 1.3 Planning Sprints
- 1.4 Managing Work
- 1.5 Sharing Outcomes
- 1.6 Improving Processes
- 1.7 Communicating About Processes With Community And Other Stakeholders
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 and Assessing Opportunities
The MDN Opportunity Assessment Process enables MDN team members and contributors to submit "big" ideas to improve MDN, through reviewing, approving, tracking, and planning their implementation, with enough lead time to review and appropriately plan prior to implementation.
- Propose opportunity: If you have an idea for an opportunity for MDN, complete the MDN Opportunity Submission Form.
- Review: Proposed opportunities are reviewed in a weekly meeting. If you submit a proposal, please attend the next meeting, if possible, to make the case for your proposal. See the complete set of submitted proposals.
- Decision: Will the proposed opportunity go into the Prioritized Backlog?
- If the idea passes initial review, it is placed in Prioritized Backlog (Product Decision Matrix with ranked opportunities).
- Assess top opportunity (target market, size, scope, etc.)
- Decision: Do we move forward with implementing the top opportunity?
- If yes, add it to the Product Backlog and in Taiga, as a draft Epic; if no, the opportunity is discarded.
- (Approx. 2 months before target implementation): Research feasibility of opportunity and work involved; decompose the Epic into User Story(ies) and Tasks.
- (Approx. 1 month before implementation): Sprint/Quarter pre-planning phase; determine which user stories in the epic will be part of an upcoming sprint.
- (Approx. 3 weeks before implementation): Sprint planning for target sprint; refine user story if necessary.
- (2.5 weeks before implementation): Start sprint; execute user story work.
Weekly Review Meeting
- Time & Location: Thursdays, 9:00 AM Pacific Time, in the MDN Vidyo room
- Optional to attend--but recommended if you’ve made a submission for review, so you can defend your idea. If you are unable to attend, enlist an ally to attend and support your proposal in your place.
- Chaired by the PO.
- "20 item rule" - Are there are 20 other proposals in the queue already?
The backlog is capped at 20 items. Even if we deem the opportunity promising enough to go forward, it must be better than one of the items already in the backlog, if there are more than 20 items.
If the proposal is not added to the backlog, then it goes back into the opportunity pipeline, and will be reviewed again the following week. (Submitter can refine opportunity in the meantime.)
The Product Backlog is also ranked in terms of priority and capped at 20 items, so if the top opportunity in the Prioritized Backlog doesn't rank above the #20 opportunity in the Product Backlog, it is discarded.
- Taiga backlog
- List of epics
- Old list of Epics (as issues, prior to built-in support for epics in Taiga)
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.
As of October 2016, Taiga added built-in support for epics, so that user stories are linked with the epic they are associated with.
Previously the MDN team represented epics 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.
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
- Marketing initiatives
- IT infrastructure requirements and deadlines
Quarterly Key Results are listed on the MDN Durable Team's wiki page. Starting in Q2 2017, the team creates a Project document for each Key Result, linked from the wiki page. These documents summarize the purpose, success metrics, accountability matrix, and other key elements of the project.
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 (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 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.
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, development, and community areas work separately to select and flesh out the User Stories in each area, so that they are ready to be placed in the Task Board. 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. User stories are given "t-shirt" (S/M/L) size estimates, and confidence ratings (High/Medium/Low). The size estimate categories are based on the number of days they are expected to take to complete:
- a few days
- about a week
- more than a week, up to the whole sprint
The team's committed User Stories are shared with the broader Marketing team.
When prioritizing and planning a sprint, it is a good idea to consider "What will we want to demo at the end of the Sprint?" The user stories that are expected to lead to demo-worthy accomplishments should therefore get a high priority.
- Taiga backlog
- MDN 2016 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:
- The user story is proposed, but incomplete.
- The author has added Acceptance Criteria and Tasks; it is ready for review by the team.
- The team accepts the user story as complete; it is ready to be prioritized and pushed into a sprint by the Product Owner. It must have acceptance criteria and tasks.
- 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 by the Product Owner.
- The Acceptance Criteria and Definition of Done have been met.
- 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 ??).
The following practices concern maintaining user story status:
- User stories that are abandoned in the Draft or New states are deleted from Taiga.
- 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 back to the backlog (with an explanatory comment).
- If a user story is removed from a sprint back to the backlog, it should be moved back to the Ready state.
- When all tasks are completed on a user story, it must be manually moved into Ready for Test by the owner of the user story.
- If a user story is in Ready for Test, 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 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, 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.
- Task board for the Sprint; each one has a unique URL within Taiga.*
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):
- Planned, not being worked on at the moment
- In Progress
- Currently being worked on
- Ready for Test
- Completed, needs test or review
- 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.
- Team members are encouraged to touch a card a day; that is, move or comment on at least one task card each work day. If a task takes more than one day to complete, add a comment about what was accomplished (or roadblocks, etc.); also add a comment when you move a card into "Ready for Test".
During the 12 work days of a Sprint, team members meet in a regular Standup meeting (typically twice a week, split by functional area). 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 by team member).
In addition, the MDN team holds a Mid-sprint check-in on the second Tuesday of the sprint.
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).
- Google Slides
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.
The MDN durable team uses a slightly different structure for the retrospective discussion:
- General observations
- What worked well?
- What didn't work?
- What steps will we take to improve?
If the team decides to change processes that are documented in this article, then this article will be updated to reflect the change.
- 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 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 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 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.