MediaWiki

Discovery/Meetings/Rethinking portal planning 2016-02-03

< Discovery

The Wikimedia Discovery Portal team met to discuss how to optimize their regular planning meetings.

Current meeting schedule

edit

One 1 hr/wk planning meeting which includes:

  • standup
  • backlog grooming
  • "sprint" planning
  • discuss technical issues
  • etc.

Plus 2 other standups/wk

Big question: kanban vs. scrum

edit

Switch to a scrum-like fixed-length iteration?

  • Probably not yet--new team w/Deb; wait a month or two

Ideas

edit

Would like to move to a bit more structure, knowing what's coming up in the near term

Could use more knowledge about how long stuff will take (and where the unknowns are). Have better understanding of all the steps to get from here to the goal. (e.g. releasing to production).

Deb is still getting up to speed with existing tasks. Dependencies. Must-have vs. not.

Meetings should be structured. Have an agenda. Meetings become quicksandy mess, without a specific goal. Cut people off if they talk too long. +1

Have a mechansim to alert when the discussion is getting into the weeds or off-track:

Do homework between meetings. Be prepared before arriving.

Would be good for meetings to result in concrete action items

Really like the To Discuss column. Maybe needs less attention in meetings because they have activity in the phab tasks themselves.

Deb asks: Is asking questions in phab comments the best channel?

  • It can work
  • But phab notifications can get lost in the noise, so emails to the side can be helpful
    • Email about content would go to the public list, but requesting phab activity would be private
  • Phab can be configured to filter out some notifications, which can help quite a bit
  • For time-sensitive or very important issues, reaching out via email or IRC makes sense

IRC norms

  • Use private irc or discovery channel? Favor public unless there is a reason to go private
  • How much do people pay attention to IRC?
  • Should we have a portal IRC channel? Probably not (silos)
  • IRC is lossy--if someone didn't acknowlege your message, assume they didn't/won't see it

What planning activities should involve the whole group?

  • Look at "what's next" (which is a column)
    • When a dev needs work, should pull from the top of "what's next"
  • "Design Work" column is just Deb/Moiz
    • So probably not a group activity
  • After getting through "what's next", should move to "To Discuss"
    • Deb has looked at these. Further down the road (2-4 wks)
  • Backlog items would get pulled to To Discuss
  • Estimation should happen in the To Discuss column
    • Ideally soon after it is added to that column, but after necessary discussion

Proposed topics to be included in planning meeting

1. Estimating what's in To Discuss

2. Discussing what's in To Discuss

2.5 Add newly-discovered related tasks

3. Review "what's next"

4. Could start to estimate backlog, time permitting

Standups should cover Current and Whats Next

Decisions/next steps

edit
  • Stay with kanban for at least the next month or so
  • Keep the current meeting schedule (1 hr/wk plus 2 other standups)
  • Kevin to propose a specific standing agenda for the planning meeting (something very similar to what appears above)
  • During tomorrow's estimate-a-thon: Get estimates for all Current and What's Next, and start on the To Discuss
  • Everyone will help keep the conversations focused ("kittens!")
  • Everyone should try to do prep/homework outside/before meetings to make the meetings as efficient as possible
Retrieved from "https://www.mediawiki.org/w/index.php?title=Discovery/Meetings/Rethinking_portal_planning_2016-02-03&oldid=4810378"