Program Management/Sprint Guide

Overview

Let's come up with a set of common things between projects. Let's consider an iterative approach; adapting, evaluating how we make software. In software development, we often fall into design patterns like MVC. Why not consider a design pattern for how we build software?

Why?

There's a lot we can improve on at Mozilla. From how we define products, plan, execute, and deploy. How can we ship software with less chaos? How can we organize to maximize efficiency. How can we make planning slightly more predictive than a wild ass guess? How can we iterate and change course more quickly? How can we deploy, measure, and adapt?

Outcomes

• Eng: Improve efficiency through effective communication, and peer-to-peer ownership of a feature within a sprint team.
• Eng: Identify and resolve blockers more quickly with quick huddles after stand ups.
• PM: Improve the relevance and value of the products by tightening the feedback loop from hypothesis to testing to adaptation.
• Team: Two week iterative reviews allow the team to set and review task priority in a sane manner.
• EPM: Improve ability to plan a release so product decisions can be made earlier in cycle.

Core principles and rules

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

--Agile Manifesto

• http://www.agilemanifesto.org/principles.html | counter point
• There are no rules.
• The team defines the "process", not the process defining us.

Events and Actions

• 2 week iterations
• 1 Sprint Planning Meeting: to define and prioritize the high level goal and backlog
  • All tasks in Bugzilla with rank, iteration, whiteboard themes, and priority
  • Planning poker or assigning sizing of tasks is TBD
• The team pick up tasks and update bugs in preferably the order of task rank (what makes sense).
• The team chooses frequency of standups
  • Stand ups are streamlined meetings where each person provides status on what they worked on yesterday, today, and if blocked. Any questions or blockers should have a quick break out session after.
• Sprint Review: Review deliverables, often demos, and hold a retrospective.

Optional

• Scrum Teams don't contain any team members who don't do tasks other than a Product Owner. See chickens and pigs cartoon