Confirmed users
964
edits
Program Management/Sprint Guide: Difference between revisions
fff
(→Events and Actions: f) |
(fff) |
||
| Line 1: | Line 1: | ||
== Overview == | == Overview == | ||
Let's come up with a set of common things between projects | 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? == | == Why? == | ||
How can we ship software with less chaos? How can we organize to maximize efficiency. How can we make planning slightly more predictive? How can we iterate and change course more quickly? How can | 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 == | == 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. | |||
== The Rules == | |||
* There are no rules. | |||
* The team defines the "process", not the process defining us. | |||
* The team refines the process each iteration. | |||
== Events and Actions == | == Events and Actions == | ||
* 2 week iterations | * 2 week iterations | ||
* Sprint Planning Meeting: to define and prioritize the high level goal and backlog | * 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 | ** All tasks in Bugzilla with rank, iteration, whiteboard themes, and priority | ||
** Planning poker or assigning sizing of tasks is TBD | ** 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. | ** 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 what was 'done' for the sprint, demos, and retrospective (what went well and not so well). | * Sprint Review: Review what was 'done' for the sprint, demos, and retrospective (what went well and not so well). | ||
== Optional | == Optional == | ||
* Scrum Teams don't contain any team members who don't do tasks other than a Product Owner. | |||