Contributors/FY2016-17Q2/Planning

FY2016-17Q2 refers to October-December 2016.

Proposed Steps for finalizing Editing Department Q2 goals
Who: Editing Department Directors, Managers, Product Managers, Designers and Lead Engineer
 * 1) Trevor announces start of process
 * 2) Aug 16-18: Joel and Trevor make first draft of SOP
 * 3) Aug 19: Managers review and refine SOP
 * 4) Aug 22-26: Managers execute the SOP
 * 5) Aug 27: Publish first draft of Department team goals
 * ? : coordinate with other Departments
 * ?: finalize for quarter
 * ?: Do next quarter's planning
 * ?: review after end of quarter
 * 1) Sep/Oct: retrospect on the process

DRAFT Standard Operating Procedure


This process will enable you to select quarterly goals and narrow them down to a focus goal to publicly communicate and track. 
 * 1) Carry-over goals: Anything that didn't get completed from the previous quarter needs to be continued or stopped.
 * 2) New goals: Select work that is called for in both the annual plan and roadmaps of products your team is responsible for.
 * 3) Capacity check: Reject goals that will take more than half of your team's capacity, starting with the lowest priority first.
 * 4) Team check: Discuss the goals with your team to ensure alignment and collaboratively make improvements.
 * 5) Get feedback: Attend an Editing Goals Jamboree meeting to receive and provide feedback on goals, including which to focus on.
 * 6) Dependency check: Confirm agreement for any prerequisite work your objectives will require other teams to do.
 * 7) Publish a draft: Fill out your portion of the "Editing FY2016/17 Quarterly Goals" spreadsheet by August 27th.


 * 1) Recycle Q1 plan to create first cut of Q2 plan
 * 2) Cut everything that's done (but check for successor goals)
 * 3) Anything that's left should be at the start of the Q2 plan.
 * 4) if not, why not?  Are you cutting something? (GOTO cutting procedure)
 * 5) Sync Product Roadmap(s) with Q2 Plan
 * 6) Assumes the Product Roadmap is freshly groomed, meaning that the top N items are correctly prioritized and ready to start work on
 * 7) What's the next thing on your product roadmap(s)?  Do one of:
 * 8) Add it to Q2 plan.
 * 9) Skipping it.
 * 10) Should you cut it instead?
 * 11) Cut.
 * 12) GOTO cutting procedure.
 * 13) Repeat until capacity reached
 * 14) What is capacity?
 * 15) Base on last Q.
 * 16) Can you quantify in any way?  By points, # of tasks, # of features, # of releases?
 * 17) A quantified baseline, even a very crude one, is surprisingly accurate (if not precise).
 * 18) Should there be full two-way sync between Q2 plan and product Roadmaps?
 * 19) Yes, or else your roadmap is junk?
 * 20) No?
 * 21) overkill?
 * 22) What if roadmaps don't exist/don't line up (e.g., not all Qplan work is product work, and roadmaps are mostly for products)
 * 23) Synchronize Annual Plan with Q2 plan
 * 24) Sync your draft Q2 plan to the Annual Plan
 * 25) For each item in your Q2 plan:
 * 26) Does this match something on the annual plan?
 * 27) Yes.
 * 28) Map it: In the Column B of the Quarterly Plan spreadsheet, indicate which Annual Plan item this applies to.
 * 29) (n.b. should the roadmap also be synced to the annual plan? if so, when and how)
 * 30) No.
 * 31) Are all of the existing objectives in the annual plan already covered?
 * 32) Yes
 * 33) Add the new thing and notify Trevor.
 * 34) No
 * 35) Ask Trevor for help judging priorities and cost/benefit of new thing ahead of existing to Annual Plan objectives.
 * 36) Sync the Annual Plan to your Q2 plan
 * 37) For each item in the annual plan, is it relevant to your team?
 * 38) No
 * 39) Next item
 * 40) Yes
 * 41) Is there something on your Q2 plan that maps?
 * 42) Document the match by populating column B in the Q2 plan
 * 43) Nothing matching on the Q plan.
 * 44) Can you do it this quarter?
 * 45) Add to Q2 plan and roadmap.
 * 46) No match, and should be cut from annual plan
 * 47) GOTO cutting procedure?
 * 48) Capacity Check
 * 49) Now that the Q2 plan includes leftover Q1 items, the top of the roadmap, and Annual Plan items, do you have capacity to do all of it?
 * 50) Reconfirm priorities of everything in the Q2 plan.
 * 51) Estimate where the cut line should be.
 * 52) Cut everything below the line.
 * 53) GOTO cutting procedure
 * 54) Sync with other teams in Editing department
 * 55) Details TBD.
 * 56) Go and talk anyone you have a dependency with?  Swap plans?  When?  What about circular/mutual?
 * 57) Is this at the Jamboree?  Before the Jamboree with finalization at the Jamboree?
 * 58) Sync with other teams in other departments
 * 59) Is this before or after Aug 27?
 * 60) Details TBD
 * 61) Another capacity check?
 * 62) Before Aug 27, have will have a meeting where we discuss each other's goals and provide feedback and resolve dependencies. More info on the timing of that meeting will be coming soon.
 * 63) Publish a draft (as in, mostly there but could still change) on MediaWiki.org on the 27th of this month (about 2 weeks from now).

Cutting procedure:

 * 1) Is anybody else's work dependent on item?  If so, discuss with them.
 * 2) Is this on a product roadmap, or part of the annual plan?  If so, [TBD]

Documents

 * 1) Editing Department FY2016-17 Quarterly Goals
 * 2) Product Roadmaps
 * 3) Annual Plan
 * 4) A copy of relevant goals is stored in the at end of quarterly goals spreadsheet
 * 5) Full Plan

= Objectives = What are we trying to accomplish with quarterly planning this quarter, and with an SOP?
 * 1) At the individual level (Team participants and managers)
 * 2) Make quarterly planning less unfun
 * 3) Provide emotional payoff to work from last Q.
 * 4) Work isn't wasted for audience: Sense that the planning and reporting work is being seen at all, is being seen fairly, and leads to reasonable consequences
 * 5) Work isn't wasted for me: I can re-use and build on it, and am not repeating myself
 * 6) Make it cheaper and less painful to do planning
 * 7) Reduce the blank-page pain of Qplanning
 * 8) Take away the mystery of the process.
 * 9) Build repeatable (cheaper) habits.
 * 10) At the team level
 * 11) Get more value out of the old planning work - we aren't smarter, and only know a little more, so that work should still be mostly valid.
 * 12) Follow up on existing work, don't re-invent
 * 13) Existing plans and roadmaps should already be long-term, span quarters
 * 14) Shouldn't be very detailed in the far future, but more than nothing
 * 15) And work not completed should be pretty detailed already
 * 16) If we are changing from previous plan, need to communicate that
 * 17) At the Department level
 * 18) Become more realistic about planning
 * 19) Force us to confront stuff that doesn't work - fix it or flag it
 * 20) Get more stuff on
 * 21) Don't commit to do too much.
 * 22) Commit to work representing about half of the team's capacity under ideal conditions.
 * 23) Use reporting (n.b. Phlogiston reporting to reality check.  Collab example)
 * 24) Coordinate with other teams' plans
 * 25) Know what each other are doing
 * 26) Get peer feedback on plans
 * 27) Get peer input on priorities
 * 28) Get peer input on best approaches, previous efforts, etc.
 * 29) Resolve dependencies between teams
 * 30) At the Foundation level
 * 31) Correlate to Annual Plan
 * 32) Comply with rules for planning Column B - show which Annual Goal relates.  (why?)
 * 33) follow the annual plan?  (i.e., would pass a cross-check)
 * 34) Reuse the annual plan so as to reduce new planning efforts
 * 35) Build trust with movement
 * 36) Demonstrate that we are able to meet our commitments
 * 37) Demonstrate that we give them advance notice and consultation if we need to change those commitments.
 * 38) Bring and keep Roadmaps current and relevant.
 * 39) Be on time syncing with other teams.

Why this won't work (and what to do about that)

 * work is too complicated or changes too frequently to fit either the quarterly plan model or this SOP
 * Work is not a linear, fungible quantity (e.g., do 20 hours of development and it's done) but instead can be:
 * Non-linear/unpredictable
 * Dependent on other teams/other parts of the WMF
 * Dependent on non-software factors such as community acceptance