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

By on in Process

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.

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. We 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 with us to build great products, we would love to talk!


Interested in more software development tips and insights? Visit the development section on our blog!

Now hiring developers, designers, and product managers.
Apply now: www.carbonfive.com/careers

Human-Centered Learning Loops with IDEO

By on in Design, Events

Carbon Five San Francisco hosts Talk Nights and invites the community to join the conversation on how we can build better products together.

This month we were joined by two guest speakers from IDEO, Kaitlyn Irvine, an Interaction Designer, and Nadia Surtees, a Design Researcher. Together, they discussed Human-Centered Learning Loops and some of their recent user research projects done by IDEO in collaboration with Carbon Five. Continue reading …


Working with Guests: Seven Tips for Getting your Company Ready to Leverage External Firepower

By on in Process

Companies have been successfully partnering with consultants since the dawn of time. Think IDEO’s work with Apple to create the mouse or Microsoft’s work with IBM to create MS-DOS. Our nation’s competitive strength comes, in large part, from this openness to collaborate, to learn from each other, to move quicker, and to leverage outside strengths, when needed and without shame.

Regardless of where you stand on the topic of partnering, there is one thing you have to realize. If you’re in tech and growing fast, there is a high likelihood you will have to partner at some point to meet your goals. Today’s labor market is just too tight to fill all the demand for experienced software talent.

Continue reading …


Cross-Platform Elixir Releases with Docker

By on in Development, Docker

Deployment, despite being an essential task, can be a confusing part of shipping an application. Depending on your stack, there could be a plethora of tools out there or… none at all. Unfortunately, Elixir falls into the latter bucket. Despite having a heart of gold, the language is still obscure, and that makes the process of deployment a tiny bit harder.

Addressing this problem may have been the reason for incorporating releases into version 1.9 of the language. Since the version bump, Elixir Releases have received the official blessing of the core language team. That means that deployment will finally be a piece of cake… right? There’s a caveat. While releases are meant to be self-contained executables, they still call out to native system libraries to do things like open TCP sockets and write to files. That means that the native libraries referenced at compile time need to be exactly the same as the ones on your target machine. Unless you can guarantee that your workstation and cloud are exactly the same, releases can seem like only half the promise of a stress-free deployment.

Continue reading …


Migrating From Sprockets to Webpacker

By on in Development, JavaScript, Rails

Starting with Rails 6, Webpacker became the default asset compiler, replacing sprockets–better known as the asset pipeline. While the asset pipeline was a big step for its time in making it easy to package JS, CSS, and images, webpack has matured enough to do all of the above and more, due to modern JavaScript’s support for modular imports and exports.

Why Migrate?

Personally, the biggest benefit of webpacker is how it encourages me to think about structuring assets as components so that they are theoretically portable and do not rely on hidden globals. And by using an extensible tool like webpack under the hood, you can take advantage of popular plugins and customizations to tune what you need – like deduplicating shared imports, in both JS and CSS. Finally, you’re not limited to just extending webpack: it’s much easier to tap into the huge ecosystem of npm packages.

Below is a breakdown of how to start moving from sprockets to webpacker.

Continue reading …


Running Multiple Versions of Postgres with Docker Compose for Local Development

By on in Development, Docker

Say we have Project X and Project Y that require Postgres 9 and Postgres 10 respectively. These projects aren’t using Docker to manage their Postgres dependency so it is up to each developer to manage this themselves. How do we get different versions of Postgres running simultaneously on our workstation without making any modifications to these projects? One easy way is to use Docker Compose.

Why not Homebrew? With Homebrew, installing multiple versions of Postgres is easy, but running them simultaneously is cumbersome. With Docker Compose, both installing and running are easy. Note that we’re not “dockerizing” the applications themselves; instead, we’re using Docker Compose as an alternative to Homebrew to fetch and run Postgres. Continue reading …


Why Write Good Pull Requests?

By on in Development

What is a pull request?

Pull requests let you tell others about changes you’ve pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.

Github

Many development teams use pull requests as a way to control and socialize the code changes made for a given project. They serve as documentation for the development process as well as a tool to discuss and review the changes. They can also inform future developers about the reasoning behind a particular implementation or coding pattern by including notes about the current state of things when the pull request was originally submitted.

Continue reading …


Don’t Drop the Ball on the Demo

By on in Product Management

Every once in a while an embarrassing product demo gets captured in the media and we all hold our collective breath as the latest source of escalated hype plummets back down to the ground. A version of this happened a few weeks ago when Tesla attempted to show off the “armor glass” on its new Cybertruck model by slinging a metal ball at the window, leaving CEO Elon Musk blinking in the limelight as CRACK,  glass shattered to the floor.

Well, that was not supposed to happen…

Continue reading …


Ground Control to Major Tom: How to Excel in Remote Research

By on in Design, User Research

There is never a ‘good time’ to do research, but we can at least all agree when and why it is necessary for strategic product decisions. What happens when the only research you can fit in your project is remote – with participants and with a co-located team? Before you cringe, pull your hair, or just laugh – here are some techniques we learned during our recent engagement with DailyPay.

Continue reading …


The Best of Both Worlds: HTML Apps & Svelte

By on in Development, JavaScript, Open Source, Rails

At Carbon Five we try to be agile about our technology choices and pick the simplest tool for the job at hand. That means that even in 2019, the era of React and Redux and GraphQL and all the other fancy tools for client-side web applications, sometimes the best tool for our clients is a good old Rails app, serving HTML.

Often the vision for the project pushes us towards a Single Page Application instead — maybe the app is going to be highly interactive or include realtime data, or the client is already invested in a front-end framework. In those cases, of course, we’ll reach for React or Angular or Vue. But for the traditional CRUD app that just needs to show some data and let users update it, a small team of experienced Rails developers can get an idea to market incredibly quickly.

Continue reading …