Engagement/MDN Durable Team/Agile glossary: Difference between revisions
(Created page with "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. ===Acceptanc...") |
No edit summary |
||
| Line 3: | Line 3: | ||
===Acceptance Criteria=== | ===Acceptance Criteria=== | ||
Verifiable work products or achievements that together are necessary and sufficient to implement a User Story. | Verifiable work products or achievements that together are necessary and sufficient to implement a User Story. | ||
===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 [http://www.agileiowa.org/articles/2013/12/08/finding-your-own-durable-team/ Finding your own durable team] for a detailed explanation. | |||
===Product Owner=== | |||
The person ultimately responsible for the product being worked on. This role creates the product vision, approves works, and communicates with stakeholders. | |||
===Scrum Master=== | |||
A project manager who drives projects, manages the team's process, removes blockers, and facilitates meetings. | |||
===Sprint=== | ===Sprint=== | ||
A set period of time designated to achieve a body of work. Currently, | A set period of time designated to achieve a body of work. Currently, Mozilla Marketing teams use 3-week sprints, which consist of 12 days of active work time, and 3 days for review of the past sprint, planning of the next sprint, and miscellaneous non-sprint activity. | ||
===Sprint Board=== | |||
A visual representation of the team's work. | |||
===Stand-up=== | |||
A daily, brief (15-minute) meeting, in which team members discuss what they've done, what they plan to do, and anything blocking their work. | |||
===Task=== | ===Task=== | ||
| Line 17: | Line 32: | ||
: As a (role), I want to (activity), so I can (goal). | : As a (role), I want to (activity), so I can (goal). | ||
One exception is when the team does not have enough information to formulate a user story in this format. These are designated by "[Research]" in the description, and should have Acceptance Criteria that will enable creating future | One exception is when the team does not have enough information to formulate 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. | ||
Revision as of 22:34, 28 June 2016
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 or achievements that together are necessary and sufficient to implement a User Story.
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.
Product Owner
The person ultimately responsible for the product being worked on. This role creates the product vision, approves works, and communicates with stakeholders.
Scrum Master
A project manager who drives projects, manages the team's process, removes blockers, and facilitates meetings.
Sprint
A set period of time designated to achieve a body of work. Currently, Mozilla Marketing teams use 3-week sprints, which consist of 12 days of active work time, and 3 days for review of the past sprint, planning of the next sprint, and miscellaneous non-sprint activity.
Sprint Board
A visual representation of the team's work.
Stand-up
A daily, brief (15-minute) meeting, in which team members discuss what they've done, what they plan to do, and anything blocking their work.
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.
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 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.