Modular Milestone-driven Development
This section is currently a draft.
Material may not yet be complete, information may presently be omitted, and certain parts of the content may be subject to radical, rapid alteration. More information pertaining to this may be available on the talk page.
- Track work more consistently
- Use Milestones to define Wikimedia Foundation's scope of work (the “X Board”).
- Try to tie high-level goals all the way through to small tasks (may not pass cost/benefit test)
- Sync everything. Keep our high-level and low-level goals in sync (but not so much, or in a way, that we do more paperwork than other work)
- Change how we plan so that changing scope is inseparable with changing priorities and changing staffing.
- Continuity of planning; stop re-inventing, maintain institutional memory over years, especially when that memory is mostly outside the Foundation.
- Quarterly goals, weekly or bi-weekly sprint planning or Kanban checkin, should start with last period's goals and show deltas
- Become more realistic and evidence-based in planning and evaluation.
- Note that these can be in conflict; it may not be realistic to collect enough evidence to be confident in a decision.
- Separate Outcome Dashboard from Output Dashboard.
- Use Output dashboard to evaluate what a team has completed.
- Use Outcome Dashboard in prioritizing which outcomes to try and change and which projects to staff up to do so.
- Collecting data about whether something worked is itself work. If we do something in Q1, we may not know if it worked until Q3 or even never.
- output vs outcome. when evaluating the results of work, checking that the team completed the output they intended to complete is a different thing than checking that the output caused the desired outcome.
- noise of change is really signal.
- Traditional gantt charts, and even quarterly goal setting, can induce the tendency to see changes from the plan as problems to be minimized. However, the reasons for these changes are generally the reasons why the plan is bad or incomplete or impossible, so we should be treating these changes as signal to incorporate into the plan. And we should have a process that encourages rather than discourages this. (which is what?)
- evidence-based narrative. The stories we tell ourselves about what we are doing and how it is working should be grounded in evidence where possible, and bounded by caveats (and plans for tests) where not.
Basic mechanism in SPDPP
- make goals.
- do work breakdown
- do work and track work
- evaluate against plan repeats at at least three different levels
Cycles where this applies
- outcomes to outputs
- outputs (quarterly goals) to milestones
- milestones to tasks
One possible way to understand and consolidate the different, related terms used for work tracking at the Foundation:
|Concept||Also called||Example||Limits||How is it documented? (and where?)|
|Objective||Goal, Quarterly Goal||"Improve language support for search"||Wiki page|
|Key Result||Metric, Measure for Success, Goal, Outcome||"Improve search user satisfaction by 10% (from 15% to 16.5%)"||Must be measurable (could be qualitative measurement).||Wiki page|
|Milestone||Goal, Output||"Run an A/B test for a feature [X]"
"Determine from A/B test results whether this feature is fit to push to production [likely to achieve Key Result]"
"Push feature [X] to production"
"Measure change in search user satisfaction due to feature [X]"
|Small enough that one team can complete multiple milestones in one quarter.||Wiki page
possibly a tagged Phabricator Task
|Epic||Saga||"Build feature [X]"||Any "Task" bigger than the definition of Task below.||Phabricator Task|
|Task||Story||"Determine schedule for A/B Test for feature [X]"||Within Scrum, a task has a maximum amount of effort, often a few days of work. Any task likely to be larger, or any task already that big, should be considered an Epic, and should be further decomposed into smaller Tasks before work proceeds.||Phabricator Task|
Coming soon: Slides 44 to 61 from SPDPP Proposal
Changes compared to status quo: