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.
Verifiable work products, conditions, or achievements that together are necessary and sufficient to implement a User Story.
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.
A tangible work product completed within a quarter (3 months) in support of an Initiative.
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.
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.
Taiga now has built-in support for epics, as well as dedicated view of epics. Prior to this change (approx. October 2016), the MDN durable team used "issues" in Taiga to represent epics, with tags based on the issue number to associate User Stories with their corresponding epic. With the built-in support for epics, user stories can be directly associated with the epics they belong to, and the progress of an epic can be tracked based on the progress of the associated user stories.
A priority area of investment with a specific audience, which affects a KPI and will require a minimum of 6 months to complete.
Key Performance Indicator, a metric that indicates how well the team is achieving its mission.
[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.
[Meeting] This 15-minute 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, usually the 6th or 7th work day.
[Role] The person ultimately responsible for the product being worked on. This role creates the product vision, approves works, and communicates with stakeholders.
[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 continue doing?
[Role] A project manager who drives projects, manages the team's process, removes blockers, and facilitates meetings.
A set period of time designated to achieve a body of work. Currently, Mozilla Marketing teams use 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.
[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.
[Meeting] 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.
- Team members are required to attend; if attendance is not possible, email the team with status.
- Stakeholders are welcome to attend, but should primarily listen.
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.
A visual representation of the team's work plan and status for a Sprint. Also called a Sprint Board.
The MDN durable team uses Taiga for its task board.
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.)