What Are These $%^&* Chores Doing in My Backlog!

Beyond Just Features and Bugs #

Projects tend to have three types of “tasks” for developers to do: features, bugs, and chores. Features and bugs are mostly self-explanatory. Features deliver direct customer value. Bugs are features that are not working as intended. These two tasks focus on direct connections to the users. Chores provide indirect customer value. Indirect value can be hard to identify as it can come through a variety of paths.

Chore value identification happens before or during prioritization. Chores should be prioritized along with features and bugs in your normal process. Before the work begins, the full team (composed of development, design, and product roles) needs to cultivate a shared understanding of the chore and the value it targets through discussion. Give everyone a chance to provide input into the work and understand priority in the larger context.

The rationale for chores falls into about six categories.

Spikes #

A spike is used to investigate or understand potential future work better. Often timeboxed, it provides a short exploratory time before starting a solution to fill in the details, discover options, or make choices. Some spikes help with understanding the scope of an integration, checking if there are technical limitations on the desired feature, or exploring the pros and cons of ways to achieve an outcome. When writing the spike definition, define an explicit goal for the given time to limit endless exploration. While spikes may not produce production code, they provide valuable information for planning and more accurate estimations for the resulting future tasks.

Infrastructure #

Even if you have a dedicated infrastructure team, the development team will be managing and/or maintaining at least some of the infrastructure around software. Software is more than just the code for the product. There are the tools developers use to write the software such as code repositories and local development setup. After the product code is created, servers need to run, test, and deliver the software to the customer. Automated testing and deployment are time-saving and create a safe environment for new features. All these pieces need to be working properly for code to be written and distributed safely.

Developer Efficiency #

Developers care a great deal about efficiency. Efficiency chores can pay dividends down the line. Cleanup (or refactoring) is the task of taking existing code and changing it to be “better” without changing the features for the user. “Better” is usually defined as more stable and easier to build on. Other time-saving tasks reduce the waiting time for code to build or run. These chores should have a direct impact on the speed of future development of features.

Image Credit: https://xkcd.com/1205/

Security & Dependency Updates #

Software is built upon a multitude of dependencies and underlying frameworks. These drastically improve productivity, but, like all code, may have security updates and bug fixes. Keeping dependencies up to date usually needs to be done for the security of users and the company. Some teams consider security updates as high priority bugs, but generally checking dependencies are up to date is a good practice and chores are a great way to surface and prioritize the update work with the team.

External Constraints #

Similar to the underlying dependencies, relational and external dependencies also need attention at times. External dependencies are usually APIs or other services provided from outside the company. Even large companies like Google shutdown older versions of their APIs after they have been superseded for several years. Security certificates and other licenses expire and need to be updated. All these are external constraints that have hard dates attached to them. If an API shuts down on May 31st, the upgrade or migration needs to be completed, tested, and pushed to production before then. Warning: external constraint chores may start low priority because the deadline is so far in the future and rise over time as the deadline approaches. Don’t forget about or underestimate the time to resolve them!

Pre-work #

Occasionally non-user facing work is required before two or more features can be started. In these cases, it is useful to have a quick chore that gets the dependent work out of the way to allow the features to be parallelized easily. Perhaps two features both need a date picker library. The chore allows developers to synchronize on the library before the features are worked and code conflicts are limited.

These chores are best surfaced before the work begins. It can be all right to add and start pre-work on the fly, but only if it is a part of feature that is already scoped and prioritized. The break out is intended for visibility and unblocking. Make sure to link the chore back to the features and communicate the change to the entire team.

Nuance Lacking Flowchart: Feature, Bug, or Chore? #

What isn’t Worth the Chore? #

Some things are categorized as a chore when perhaps it should be a feature or a bug. It is also possible that a chore shouldn’t be done at all. Chores, just like features and bugs, can become irrelevant or lose their value. By regularly prioritizing the backlog, we can better understand the tradeoffs involved. If that cleanup chore is still there a year later, is it really worth doing? Switching technical frameworks to something newer, but no additional benefits to the customer? Many things may or may not be good to do, but just like with features and bugs, we can better understand the tradeoffs through prioritization. Justification for doing a chore is not just the value of the chore, but delaying whatever is next in the backlog.

What about ______? #

This list may be incomplete for your product, but remember that chores should provide value and you need to be able to communicate that value. The categories are meant to be useful descriptions to point to the explicit value the chore provides. For example, a piece of technical debt usually falls neatly into one of the categories in the list. If it doesn’t, perhaps the value is not well understood. Proactive management of debt is important, but that can mean just understanding and recognizing it, not fixing it immediately.

Internal technical documentation is another common “chore”. But instead of a chore, the documentation should almost always be written as a part of the feature being created. Remember that internal documentation is only useful internally. Are you creating something that is actually useful and has value or is it just documentation for the sake of documentation? Try connecting the documentation to one of the chore categories instead to expose the value being created.

Get Stuff Done; Together #

In the end, we care about getting the right things done in appropriate ways. Chores, features, and bugs are ways to help with the “right” and “appropriate” parts of that statement. No set of categories can cover all situations, and chores are a useful tool to manage and surface the needed conversations to move forward. I believe that respect for team members and the principles of transparency and shared understanding are what builds collaborative teams and great products. If you are interested in collaborating to build great products, I would love to talk!

Originally Published: Carbon Five Blog