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
- Assigning point is optional and up to the team or individual.
- 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.
Summary of Meetings:
| Meeting Type | Who | Tasks |
|---|---|---|
| Triage | Product Owner/EPM/DevMgr | Apply: priority, themes, backlog+ flag, rank. Prod Owner sets themes/rank in order of priority. Themes map back to user stories. |
| Planning | Everyone | Team tasks by setting iteration value in bug. Team sets priority if desired. |
| Sprint Review | Sprint Team | Team decides on frequency of standups and the scrum master is chosen by the team and leads this standup. Should target 15 min with any breakouts after main meeting. |
| Retrospective | Everyone | Demos of what was accomplished in iteration, discuss how sprint went, consider tweaks. |
Glossary:
| Term | Description |
|---|---|
| Rank | Relative backlog priority. For example: P1's are rank 15 by default, then lowered or increased based upon relative priority. Duplicates are fine. |
| Backlog | The set of prioritized tasks for the sprint team to complete. The product owner sets priority and team takes items in order from priority as it makes sense. We want to encourage cross training here, but want to be efficient if someone is in a specific area of code already. |
| Priority | Higher level large grouping of importance. Based upon the impact of the task or need for inclusion in the targeted release. Generally: P1 = blocker/must fix, P2 = want to fix but not blocker, P3 nice to have. |
| Theme | Large groupings of tasks in common supporting a feature. Often used to map to a user story. |
| Iteration | used to denote a team member taking an item to work on for a sprint (e.g. 41.1, 42.2) |
| backlog+/- flag | Bugzilla value that can be set to '+' or '-' for inclusion or exclusion from a backlog. |
| Points (optional) | Relative amount of work in days to complete a task assigned against the total capacity (days of work) of the team. Values follow fibonacci sequence. Optional for use of tracking velocity of team. |
Optional
- Scrum Teams don't contain any team members who don't do tasks other than a Product Owner. See chickens and pigs cartoon
