New process for managing triaged non roadmap items

MDN
#1

For a couple of weeks now we have been using a process proposed by Florian to triage bugs into P1 to P4 buckets. The idea being that P1 bugs are bugs we work on within the quarter.

We’ve come up with a bunch of them already, but no good way of actually addressing them other than ad-hoc. Last week during the triage meeting we then decided to use a combined backlog for items that are not part of our roadmap/OKR and use that for priorization, effectively combining our paper cuts backlog and the newly triaged items.

Initially we intended to spend 25% of our time on maintenance, however the AWS move made that difficult, and we didn’t follow through. As the effort for the AWS Move is winding down, we’ll have more choice again in how we spend our time on engineering issues and opportunities. My suggestion is that we estimate items in that backlog for each sprint and take on individual items to fill up 25% of our time.

Practically, we’d continue triaging using the p1 to p4 buckets every week. I’d then use the P1 list to prioritze items in Trello and during the sprint planning phase we’d estimate and move items into the sprint as dev time allows.

Let’s discuss here if you have thoughts on this.

1 Like
#2

I like the idea. I’m not sure how to implement it. Should 1 out of every 4 sprints be for maintenance? One out of every 4 quarters? We’ve often said people should get 10% time for their own non-sprint tasks, but we’ve over committed every sprint in 2017, so there’s never time left over.

We could also use a convention for estimating the level of effort needed for a bug. I think other Mozilla projects use the Bugzilla whiteboard for this, but you need to decide what your tags will be, and create dashboards for viewing them.

Links:

#3

I like the idea of trying to establish a system by which this time isn’t fleeting. Even if only 10% of our time is for non-sprint tasks, it would be better if this was accomplished by having one out of every X sprints be “free time” so to speak, rather than having to measure the number of minutes you can spent fixing non-sprint issues or maintaining older code or whatever.

Trying to do meaningful work in tiny fragments of time doesn’t usually work well, so let’s find a way to ensure that when we work on these non-sprint tasks (which are often important in their own way), we can actually get something accomplished on them.

Eric Shepherd
Senior Technical Writer
MDN Web Docs: https://developer.mozilla.org/
Blog: http://www.bitstampede.com/
Twitter: http://twitter.com/sheppy

#4

Kadir proposed a points system for estimating tasks in work days, which includes meetings, coordinating, production pushes, etc. This could be encoded as [points:X] in the Bugzilla whiteboard.

Here’s the system as I recall it:

  • 1 point ([points:1]) Trivial task. For example, setting a waffle flag in the Django admin to enable shipped, working code.
  • 2 points ([points:2]) - Less than a work day
  • 3 points ([points:3]) - 1 - 2 work days
  • 5 points ([points:5]) - 3 - 5 work days
  • More than that (points:6+) - Must be broken into smaller parts for estimating

Safwan and Anthony also requested identification of how difficult a task is, to expose tasks that could be done by volunteers. I propose a tag [lod:X] for Level of Difficulty, set to the sum of these points:

  • +1 requires additional setup beyond the basic installation instructions (such as configuring the search index)
  • +1 requires changing a little-used system (such as the API keys) or an important system not often used by staff (such as initial signup)
  • +1 requires a significant amount of production or production-like data
  • +1 requires back-end changes (views, celery workers, etc.)
  • +1 requires front-end (JS, CSS, etc.) changes
  • +1 requires database changes
  • +1 requires infrastructure changes
  • +1 requires access to production, production-like environment, or staff permissions
  • +1 requires design and specification (such as adding new workflows)

We could have the following:

  • [lod:1] - Appropriate for first-time contributors, should be assigned a mentor
  • [lod:2] - Appropriate for regular contributors
  • [lod:3] - Appropriate for advanced contributors, contractors, etc.
  • [lod:4+] - Appropriate for MDN staff

We could go above 4 as well, to quantify the effort for staff tasks, but this would go beyond the needs of identifying work for external contributors.

The whiteboard for a triaged task may then look like [specification][type:bug][points:3][lod:2]