Engineering teams can communicate their capacity for core vs new work

This goal is tracked in Phabricator as T122838. This wiki page is a prototype for performing work breakdown on this goal, experimenting with how best to mix Mediawiki and Phabricator.

The top bullets were copied in from TPG Goals.


 * 1) Documented and agreed upon definition of ‘core work’ (T122839)
 * 2) Acceptance Criteria
 * 3) All audience-facing product teams agree on and understand how to use a shared definition of 'core work'
 * 4) Documentation includes guidelines for handling work that doesn't easily fit in this framework included. (e.g., "other" (non-core, non-strategic))
 * 5) Documentation includes answers for all previously raised questions/alternate definitions (e.g., "interrupt", etc)
 * 6) Expected work sequence
 * 7) Initial definition proposed (derived from Wes's outline combined with previous efforts ( https://www.mediawiki.org/wiki/Team_Practices_Group/Measuring_Types_of_Work ))
 * 8) via email?  Via in-person at allhands?  Via strategy process?  All three?
 * 9) Request for input made to all affected teams
 * 10) Refine and finalize definition
 * 11) Review previously raised questions/issues and make sure they are addressed
 * 12) Agreed upon method for tracking data (T122841)
 * 13) Acceptance Criteria
 * 14) Tracking method exists for recording core/strategic/other in Phabricator and viewing it in reports <-- I think this needs a concept of signoff by teams
 * 15) Tracking method documented <-- I'm not sure separating "exists" from "documented" is helpful. I would just jump to "documented"
 * 16) Tracking method accommodates most common work definition patterns amongst teams <-- I think it needs to work for uncomment patterns too
 * 17) Expected work sequence
 * 18) Propose a method for tracking data, including both "total completed work" and "which tasks are core/strategic"
 * 19) Solicit input from all affected teams
 * 20) Refine and finalize method(s)
 * 21) Pilot tracking with at least one team
 * 22) Pilot reporting in phlogiston
 * 23) Audience-facing product teams able[1] to produce evidence-based data about the proportion of time spent on core vs. non-core work (T122842)
 * 24) Note that "able" is different from "willing", and even if they are able and willing, does not promise that they will actually deliver the data.  This is relevant to setting acceptance criteria that are within TPG's control.
 * 25) Acceptance Criteria
 * 26) All teams have started tracking core work, and at least one team has produced a report covering at least one week of completed work
 * 27) All teams produce report covering more than 50% of Q3 and more than 50% of total work <-- This would be above and beyond the TPG Q3 goal.
 * 28) Teams have qualitative and quantitative evidence of the quality of these metrics <-- Another stretch
 * 29) Teams have qualitative or quantitative evidence of the cost of these metrics <-- Another stretch
 * 30) Teams have performed a retrospective on the best practices for collecting this information <-- Maybe...but how many teams? Probably another stretch
 * 31) Expected work sequence
 * 32) at least 1 team produces report following these rules
 * 33) Rollout to Embedded audience-facing product teams (Android, iOS, Discovery, VE, FR-Tech)
 * 34) Rollout to other audience-facing product teams are tracking core/strategic (Reading web, Community Tech, ???)
 * 35) All audience-facing product teams are producing reports <--- Another stretch
 * 36) 2-3 teams with 2+ months of track record makes recommendations for changes <-- Another stretch
 * 37) Teams able to answer the question, "can you do X next quarter?"  <- This is out of Scope for FY16Q2, and is included for context of the broader vision of this work
 * 38) Teams have backlogs
 * 39) Backlogs are prioritized
 * 40) Backlogs are estimated/quantified
 * 41) New work is identified
 * 42) New work is estimated
 * 43) New work is prioritized relative to current backlogs