MediaWiki

Wikimedia Product Development/Product Backlog

< Wikimedia Product Development

Here are some notes on how different teams manage their backlogs. This was originally an internal email thread kicked off by Dan Garry.

A number of teams have two systems for backlog management, used together.

  • One for long-range planning. These are typically text documents, monthly/quarterly tables (spreadsheets), presentations that identify feature areas over the course of months.
  • One for sprint planning. These are typically done in project management software (e.g., Mingle, Trello)

Note from Howie: In addition to Siebrand and Steven, Maryana has two systems as well -- a 3-month view that's on a whiteboard and Mingle for the sprint planning. Mobile uses some form of this as well with their quarterly planning + sprint planning, though I'm not sure whether there's a formal doc that comes out of the quarterly planning.

Siebrand (LE) edit

I have 2 things:

Diederik's mingle practices are better than mine...

I try to set a timebox for a feature or a group of features ("Release"), so that it's done at some point, even though there may remain wishes. MoSCoW them.

Steven (Growth) edit

I also split my work into these two buckets:

Kenan (Mobile) edit

So an ideal to move towards with your backlog is that if you were to disappear, the team would not flounder.

What does that mean?

  1. Your backlog is available in a central location everyone knows about (we use mingle for project management and that is also where our backlogs exist).
  2. The backlog is groomed regularly (We have a quarterly backlog of stories - this quarterly backlog should be groomed on a biweekly basis, at the same cadence as our sprints, and at the end of the quarter a new backlog is started where you may move items over, we also maintain a bug backlog that should also be maintained regularly)
  3. Your backlog is replenished regularly (We have quarterly planning meetings which generate the bulk of the stories, you yourself should be understanding the key issues of your customers and arrange time to brainstorm solutions, there are ad hoc sort of stories that get added as you bounce around your work and meetings, we have research time for our engineers and the designers are always bouncing ideas around)
  4. There is a clear "principle" for prioritization. (In our case we have annual goals (2) and quarterly goals (3) that drive our decision making, the primary goal this quarter is to increase the number of mobile registered users that become active editors - 5+ edits, we also have a quarterly roadmap)

Point 4 is stated here as a bullet but really there is a lot that goes into this and it is the core work of us as product managers. Generally speaking I think this is a blend of building an intuition of your customers, structure that helps to clarify, and gut checking with customers either through data, interviews, or user tests.

From a stucture standpoint Maryana sent an article a while back related to this: http://www.defmacro.org/2013/09/26/products.html in particular I think that the product mission section is interesting here, as is the general idea of creating a framework, in this case three tiers, I used something similar when I worked at a company with paying customers, it's a little bit tougher in this type of environment and I haven't quite dialed into a simple system yet.

In general yearly, quarterly, sprint level themes and roadmaps are helpful. This is important not just as a way to create a sense of narrative and direction, but also because focus is a force multiplier.

Retrieved from "https://www.mediawiki.org/w/index.php?title=Wikimedia_Product_Development/Product_Backlog&oldid=1920659"