Engagement/MDN Durable Team/Agile glossary

This page defines terms used in the context of the MDN durable team agile process, to help team members and other stakeholders, including volunteer contributors.

Acceptance Criteria

Verifiable work products, conditions, or achievements that together are necessary and sufficient to implement a User Story.

Backlog

The set of Epics and User Stories that have been defined, driven by the team's Initiatives.

Definition of Done

General criteria that User Stories must meet in order to be considered "done", in addition to any Acceptance Criteria specific to the user story. The definition of done is created and committed to by the whole team.

Deliverable

A tangible work product completed within a quarter (3 months) in support of an Initiative.

Durable Team

A team using an agile methodology, where the team continues to work together on multiple projects, with minimal changes in members, over a long period of time. It is in contrast to an agile project team, which exists only for the duration of a single project. See Finding your own durable team for a detailed explanation.

Epic

A large-scale User Story that takes more than one Sprint to complete. An epic should be decomposed into User Stories that do fit within a Sprint.

Initiative

A priority area of investment with a specific audience, which affects a KPI and will require a minimum of 6 months to complete.

KPI

Key Performance Indicator, a metric that indicates how well the team is achieving its mission.

Maker

[Role] A team member who executes Tasks, collaborates with the Product Owner on vision and priorities, and decides what work gets done and when. While all team members have specialized skills, in theory, any maker can take on any Task.

Mid-sprint review

[Meeting] This brief meeting is a process check on how the sprint is going, adjustments that need to be made immediately, and progress toward completing committed user stories for the sprint. It is held near the middle of the sprint.

Product Owner

[Role] The person ultimately responsible for the product being worked on. This role creates the product vision, approves works, and communicates with stakeholders.

Retrospective

[Meeting] Held at the end of a Sprint, this meeting is an opportunity for team members to reflect on and improve their processes. Attendance is limited to core team members only in order to create a safe space for frank discussion.

During the meeting, members should consider:

• What should we start doing?
• What should we stop doing?
• What should we change how we're doing something?

Scrum Master

[Role] A project manager who drives projects, manages the team's process, removes blockers, and facilitates meetings. Also called an "agile coach".

Sprint

A set period of time designated to achieve a body of work. Currently, the MDN team uses sprints on a 3-week schedule, with 12 days of sprint work time, and 3 days for review of the past sprint, planning of the next sprint, and miscellaneous non-sprint activity.

Sprint Planning Meeting

[Meeting] A meeting in which the team finalizes selection of User Stories for a Sprint, and reviews them to ensure that the Acceptance Criteria and Tasks are well-defined and well-scoped. Committed user stories for each team for each sprint are shared with the broader Marketing team.

Sprint Review

[Meeting] Also called a "Sprint Demo", this meeting is a chance for teams to demonstrate completed work at the end of a Sprint. All Marketing Durable Teams share their work in a single review meeting, to share and celebrate everyone's work. Demos are informal, and slide presentations are discouraged. A team's demo need not cover all User Stories completed during a Sprint, but should highlight significant achievements and big wins.

Standup

[Meeting] Typically, this is a brief (15-minute) meeting that happens daily during the "work" days of a Sprint, in which team members discuss what they've done, what they plan to do, and anything blocking their work. Questions or discussions should be taken offline out of the meeting.

Task

A chunk of work needed to deliver the Acceptance Criteria of a User Story. Tasks should be defined to take about a day to complete. Tasks that require more than a day or so may need to be divided into smaller tasks. The entire team is involved in defining tasks.

Task Board

A visual representation of the team's work plan and status for a Sprint. Also called a Sprint Board.

The MDN durable team uses ZenHub for its task board; there is a browser extension that enables viewing the task board, and using related features, while working in the GitHub web UI.

User Story

A short description of a feature from the perspective of a user. User stories may be written by anyone, but the Product Owner has the final say in the wording. In order for work to begin on a user story, it must have defined Acceptance Criteria and Tasks. The scope of a user story should be small enough to be completed within a Sprint. A User Story that is larger than can be done in a Sprint is actually an Epic.

User stories typically follow the following template:

As a (role), I want to (activity), so I can (goal).

One exception is when the team does not have enough information to formulate or estimate a user story in this format. These are designated by "[Research]" in the description, and should have Acceptance Criteria that will enable creating future user stories in the canonical format. (In the Extreme Programming methodology, such an item is limited to a task, not a user story, and is referred to as a Spike.)