Modular Milestone-driven Development

Jump to navigation Jump to search


  1. 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)
  2. 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
  3. 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[edit]

  1. make goals.
  2. do work breakdown
  3. do work and track work
  4. evaluate against plan repeats at at least three different levels

Cycles where this applies[edit]

  1. outcomes to outputs
  2. outputs (quarterly goals) to milestones
  3. milestones to tasks

Data Model[edit]

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

Original Presentation[edit]

Coming soon: Slides 44 to 61 from SPDPP Proposal

Key Results Dashboard

Unsorted slides[edit]


Changes compared to status quo:

  • Input, Output, and Outcome dashboards
    Quarterly review focuses only on Outputs, not Outcomes. Separate process looks at Outcomes and decides what priorities and plans to alter.
Real data for which milestones were worked on
Relating milestones to tasks
Adding RACI to criteria
Milestones with criteria
Milestones on board
MPL to Board