Number of Assignees Over Lifespan of Ticket

Anthony McLin, 10 May 2022

If a ticket bounces around between a lot of people, that’s a good indication that there may be problems with process, understanding, team coordination, or communication challenges. The fewer the people necessary to route and complete a ticket, the more certain we can be that the team is taking ownership of work and reducing unnecessary context switching.

Never have a meeting where two pizzas couldn’t feed the entire group.

Jeff Bezos famously coined the two pizza rule to describe a maximum team size of around 6-8 people. Agile recommendations specify about the same (7 +/- 2), and there are sociological studies that indicate a team size of 7 is ideal for decision making, or a team size of 5 for satisfaction. Though a blended study finds that the magic number for efficient decision making lands at 4.6.

Formula

The total number of assignees can be determined through simple addition:

  • Na: Number of assignees over lifespan of ticket
  • Nc: Number of code contributors on a ticket (not including those already counted)
  • Nd: Number of people required to get ticket to production after the ticket is closed (not including those already counted)
  • Nr = {1 0} : Add 1 if the ticket is manually reported and is never assigned back to the reporter. Leave 0 if ticket creation is automated, or if the reporter is already in Na.
  • Nm: Number of distinct commenters on a ticket (not including those already counted)

Note that commentors on tickets are included in the score. Ideally the team should be able to deliver without additional outside inputs. If there is a Product Owner, they should be bringing the business insights and stakeholder interviews to the process. End-user input should be captured through surveys, usability testing, analytics, and other similar methods for sourcing data the team can leverage. This isn’t to say that outside comments are a bad thing, but they should be captured and reported in a actionable way, rather than simply injecting people into the process that aren’t part of the team.

Maturity Score

For executive dashboards, Maturity in assignees over the lifespan of a ticket can be conslidated to a simple aggregated score, from 0 to 5, 5 being the maximum positive score. The values should be capped at those limits.

If bug ticket capture and logging are totally automated, Nr should be 0. Likewise, if Continuous Integration and Continuous Deployment are in place, Nd should be 0. If we take into consideration the related Hit By a Bus Factor and Collective Ownership concerns, then the ideal number of assignees is around 3. So we use that to determine the max score on our scale of 5. If our maximum ideal team size is 9, then we can use that to determine a minimum score of 0.

  • Tideal: Minimum expected number of people touching a ticket
  • Tmax: Cutoff for max number of people touching a ticket
  • Mmin = 0: Minimum maturity score
  • Mmax = 5: Maximum maturity score

Improving

  1. Look for ways to automate triage steps on bug tickets, so they get to the right person with fewer steps.
  2. Try adopting techniques to do bug triage as a team so that everyone is aware of the ticket and it can get to the right person.
  3. Manage your flow by reducing the number of tickets in progress at once. Often teams bounce tickets around excessively based on capacity.
  4. Introduce Test Driven Development, so clear technical specs are produced before introducing functional code. This will reduce the back and forth caused by unclear requirements or testing assumptions.
  5. Automate unit testing.
  6. Automate QA validation.
  7. Keep team sizes small.
  8. Organize teams to be self sufficient.
  9. Reduce interdependencies between teams.

See Also