Wikimedia Cloud Services team/Team kanban practices

From MediaWiki.org
Jump to navigation Jump to search

The practices below are subject to review and change. This page should be kept up to date by the team when changes happen. The board is here

For reference on how to use the technology behind the board, look here.

Board Column Overview[edit]

Columns must have meanings and agreed upon practices to be useful to us all

  • Inbox - Kanban users also call this the "backlog". Basically everything that hasn't been touched or is not currently considered priority, somehow controversial or actively being worked on is here
  • Important - Tasks in this column are considered important to work on as soon as there is time by someone on the team. If someone disagrees with that designation, they can move it into "Needs discussion"
  • Doing - Whatever is being worked on should be here, even if just for a few minutes. This way we all know what is actually in flight. Tasks should be assigned and grouped here according to assignee, understanding that sometimes there's really more than one person working a ticket even if Phab doesn't let us show that. Part of the idea here is so that we can help each other more effectively anyway. If we know what is active, we know what is worth commenting on if we found out something to share.
    • Each person should have no more than 5 items under Doing if possible
    • In total, there should not be more than 22 items in Doing. As is, someone has too many tasks if it's that many anyway. The limits are to get a visual idea of how burdened we all are, understanding that not all tasks are equal.
  • Clinic Duty - Items specifically slated to be worked on by the on-call or that came up during the on call for quick work.
  • Needs discussion - Placing a task here signifies that this is to be an agenda item in our next meeting for whatever reason (and is not ready for immediate work)
  • Blocked - self explanatory, but this should be automatically the same as the blocks section of our meeting pad
  • Done - Ideally this will be an automated column. It is currently the most uncertain part of the board in terms of usefulness.
  • Epics - These tickets generally don't really get "worked on" on their own, but they are often linked to goals or a source of future goals. They should be tracked here so we kind of have some idea of what are non-controversial, ideally in priority order. This column is just to surface them for easy reference.
  • Graveyard - For tickets that we are not so far going to work on or never going to work on, but are things we'd like to keep an eye on.

Meeting impact of the board[edit]

  • Needs discussion is an agenda item in itself and should ideally be cleared by the end of the meeting unless more information is required for the next time we talk
  • Blocks column is the same as blocks in the etherpad
  • anything that remains in Doing from week to week might also be an automatic discussion item to help surface things that are lagging and might benefit from pairing, added assistance or escalation
  • Strictly speaking, this would be a point-in-time representation of what the etherpad actually says once a week. Theoretically, the etherpad is redundant except insofar as it can be copied into the SRE meeting pad and the fact that it is a snapshot of what the board should have said on that Tuesday. The biggest exception is the outgoing updates, which is for external consumption really.

Daily Workflow[edit]

  • check the inbox in case anything should be in "Important"
  • ensure that Doing actually represents what you are doing today as best as possible
  • shuffle things if needed

Clinic Duty[edit]

The main change here is that there is some assumption that some items might load up the Clinic Duty column, so fewer should be in the Doing column for the Clinic Duty person (or the Clinic Duty person might need some help to get important things done if there's a lot going on--not really always predictable).

Comments[edit]

The most important elements of Kanban for our team are limiting and providing visibility to work. This should help prevent important things from going unnoticed, people from being overtaxed and opportunities for teamwork from being missed. Many Kanban-like styles focus on sprints and time limited tasks. While that is useful discipline, it is far easier to apply to development than operations because of the nature of the beast.

We should mentally think of items in Doing as discrete and achievable tasks in a general sense. If they are prone to great lengths of time and lots of work, perhaps making them an epic with split up subtasks will work better for the board.