MDN/Archives/Kuma/Bugzilla Scrum

Meetings

Sprint Planning Meeting

• Time and place: The first Wednesday of each sprint in Get To Da Choppa
• Goals
  • Triage stories, "pruning" the product backlog
  • Form a sprint goal
  • Assign product backlog stories to individual team members ("the what")
  • Discuss how the individual stories will be completed ("the how")

Daily Scrum

• Time and place: Every work day in #mdn
• Goals
  • Discuss progress toward the sprint goal
  • Scrum master removes any impediments that are revealed

Sprint Review

• Time and place: The last Tuesday of each sprint via email
• Goals
  • The team shares its completed work with everyone else on the project. This can be very informal, as little as a link to the up-to-date software.

Sprint Retrospective

• Time and place: The last Tuesday of each sprint via email
• Goals
  • Everyone discusses what worked well and what did not work well in the last sprint

Roles and responsibilities

The roles and responsibilities of this team will be very similar to the roles and responsibilities outlined in the Scrum guide.

A few points should be emphasized:

• Developers, designers, copy writers, and QA engineers are all considered members of the team and are all responsible for stories.
• The team should work together to assign points to stories, since only the team has the expertise to estimate the complexity of those stories.
• We already have a good idea of what stories we will work on, but still need to convert these stories to Bugzilla bugs. The scrum master can help with this. Later, anyone should feel free to add stories to the product backlog as necessary.

Bugzilla Fields

Jay has created mockups for a Scrum dashboard for Bugzilla. Until this dashboard is complete, we will use Bugzilla fields in the following way.

• Product: Mozilla Developer Network
• Component: Website
• Version: Kuma
• Target Milestone: Used to convey the sprint in which this story will be completed. This should be left empty when the bug is first created, and later edited when the bug is triaged.
• Severity: Leave this at it's default, "normal". We will not be using this field.
• Hardware: All
• OS: All
• Priority: Used to convey priority, such that P1 stories have the highest priority and P5 stories have the lowest priority. This should be left empty when the bug is first created, and later edited when the bug is triaged.
• Assignee: Used to convey the person responsible for completing the story. This should be left empty when the bug is first created, and later edited when the bug is triaged.
• CC: lorchard@mozilla.com, lcrouch@mozilla.com, jkarahalis@mozilla.com, [others as necessary]
• Summary: Use this to provide the user story.
• Description: Use this to provide more detailed information about the story if necessary.
• Status Whiteboard: Use this to convey user type, component, and story points.
  • Use a format like the following: u=user c=wiki p=2
  • "User type" refers to the type of user that would care about this story, as in "As a [user type], I want to...". Valid choices are editor, visitor, product, and dev.