Managing a project's backlog will always be one of the hardest tasks a team has to regularly perform. The difficulty of reconciling the needs of all the stakeholders and distilling it into a succinct representation is an elusive goal. Many times these needs are hard to align because their inherent value is not easily measured. The needs of the developer may conflict with the needs of a product manager because it doesn't translate directly into something the customer wants. Likewise the needs of the product manager may not always have the necessary budget carved out to ensure the long-term health of the project.

Unfortunately for many teams it is hard to maintain a balance between these disparate goals which often results in one or more voices being neglected or ignored. It's not uncommon to see products drowning in technical debt as they chase new features and minimum-viable-product solutions. On the other end of the spectrum there are many products that stall on new features as developers spend years rewriting core functionality and ultimately lose their position in the market.

The Current State of Backlog Refinement

In it's most basic form the backlog serves as a place for team members and stakeholders to record and track work that needs to be done. Backlog management tools grew into popularity when it became clear that teams needed something more robust than simple lists to do this. Team members can now mark tasks with priority levels, collaborate and add context about the task and communicate on the progress of tasks, all in one central location.

Unfortunately, even with the best intentions this can still be too messy as multiple teams and individuals interact with the backlog with conflicting expectations, often unaware of what the other teams are doing. To fix this problem most teams perform periodic meetings to refine the backlog and reconcile these differences in priorities.

Quantifying Priorities via Investment

One of the defining features of MergeBack is the ability to allow team members to invest in backlog items as a way of measuring it's importance. Project owners can configure each project with allowance settings that can grant points to individual users or groups on a one-time or recurring basis. Those project members can then assign those points to tickets in the backlog. This simple concept creates an alternate view of the backlog that team members can switch to in order to gain additional insight in how things are being prioritized.

Example 1

Developer John has been working on the product for five years and has a decent understanding of what problems currently plague developers and customers. In particular one problem has lingered for many months but he has been unable to get it prioritized due to its low impact and simple workarounds. He is worried that it will be a much larger issue in the long run so he starts investing in it regularly. Due to the way points are allocated for the project is is not able to trivially override the primary stakeholders on the project immediately but through continued investment in the problem he is able to bubble it up to the top of the investment backlog and raise awareness.

Example 2

Similar to the previous example the support team is constantly plagued with tasks to workaround a known issue with the product but cannot seem to get traction with the development team and stakeholders to get it fixed due to its low visibility. Though the support team does not interact with the backlog in a normal manner they are still granted read-access to it and a small allowance that they can use to invest in tickets that become major pain points for them and push them to the top.

Example 3

As product manager Susan receives a quarterly allotment of points that is large enough to allow her to invest in a handful of key tickets intended to be the priority for that quarter. She can distribute the points in a way that allows her to weigh these priorities against each other to help make decisions on what has to be left out for a future quarter. Other team members lack the points to overcome these priorities in a short time frame but through continued investment they can reach the same priority level over the long term, leading to a more healthy mixture of priorities.

Example 4

Junior developer Bill has been with the company for a year and is starting to become more confident in their knowledge of the product and it's domain. There is one project in particular they are interested in working on and they start investing their points in it. These points not only help elevate visibility in the project but also demonstrate Bill's desire to work on it.

Striking a Balance

The common thread between these examples is making sure you distribute points in a way that the different voices are amplified to appropriate levels. The goal is to ensure the primary stakeholders still retain most of the responsibility in setting priorities while also making sure gap between them and the rest of the team is not insurmountable. The three mechanisms for controlling this are quantity, cadence and decay.

Quantity and cadence are mostly self-explanatory concepts. For a product manager you would want a large quantity at a slower cadence since they are expected to set priorities over a longer period time based off information that does not change frequently. On the other hand for a developer you would likely choose a much smaller quantity with a faster cadence as they're having to respond to constantly shifting priorities based off things discovered in the day-to-day operations. A developer might not be able to overcome a product manager's priority in a single quarter but continued investment over multiple quarters or a combined effort with other developers might.

Decay is a more complex mechanism intended to keep the system healthy. Without a decay users will tend to accumulate points either through neglect or intent. This becomes a disruptive force that will make the system unwelcoming for new team members and potentially lead to wild unexpected swings in priority. A decay will encourage spending and create a natural cap on how many points team members can bank when the amount they lose from the decay is roughly equivalent to the amount they gained for the previous interval.

Putting it all Together

The investment backlog is not intended to be a replacement for the familiar backlog featured in most project management solutions. It's not even the default view. At it's core MergeBack strives to be a competent solution while exploring new concepts in non-invasive ways. The main goal here is to add new context to existing conversations on prioritizing work. Context that is often dismissed because it is difficult to quantify and convey to others.