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.
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.
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.
Input, Output, and Outcome dashboardsQuarterly review focuses only on Outputs, not Outcomes. Separate process looks at Outcomes and decides what priorities and plans to alter.
VelocityReal data for which milestones were worked onRelating milestones to tasksAdding RACI to criteriaMilestones with criteriaMilestones on boardMPL to Board
