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. 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!

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 …

Each team has their own tolerance for what is and is not a reason to request changes on a PR and block it from being merged. This may be rooted in process, fairness, and expediency, and may be a company or team decision. Whatever your personal philosophy may be, the team as a whole and often the company has to come to some sort of consensus as to what constitutes a reason to block a PR. Over time, I’ve gotten a little more “block happy” and I’m going to talk about some of the advantages and pitfalls of blocking, and give you a mega list of reasons you might want to block a PR.

Continue reading …

What’s the most important meeting of your day? For everyone involved in building your product — product managers, developers, designers — it should be the daily stand-up. Where else can you learn what your coworkers are doing, get your work unblocked, and get energized, all in 10 action-packed minutes? 

It’s a simple idea that can help your digital product take shape; when a user enters your system, do you hand them a map or a path? What’s the difference? Great question, and in this case, the metaphor is pretty literal.

So you want to grow your product? That’s super awesome. Growth is often a goal that startups rush towards. 

“We need 100,000 monthly active users yesterday.” – random startup person 

Growth can mean a lot of things. Maybe you’re trying to grow the number of users, or increase time spent using your product. Whatever it is, growth usually means moving metrics. But meeting your growth goal takes a very meticulous and strategic design process. You need to try out ideas and see what actually works. In this article, I am going to share how to set up a successful experiment-driven design process that can help you identify the features and changes to grow your product. Let’s grow!

Does your product development team do a weekly retrospective? At Carbon Five, we think it’s the most important meeting of the week. Here are some tactical suggestions for facilitating a retro, so your team understands their challenges, celebrates their successes, and comes away with an actionable to-do list.  

Back at my first job in tech, we paired 95% of the time. Many people were new to pairing. As it was my first job, I was relatively one of the more junior people on the team, which is an especially difficult position to be in for pairing. It was an incredibly intense experience for the whole team with many growing pains. There was a lot to navigate and no set-aside time or structure to do that, so I started having “pairing retros” with my teammates. It made pairing a lot more manageable and I started having better experiences with my pairs. It’s now something I’ve continued to do throughout my career.

The concept is fairly simple. Set aside a time when you’re not pairing, to talk about pairing.

Ever feel like your product team is not working to its full potential? Here at Carbon Five, we’ve worked with hundreds of product teams, and we wondered what differentiated strong teams from struggling teams.

Our curiosity drove us to create the Product Dartboard, a digital tool that helps teams identify their strengths, challenges, and blind spots, and provides teams with actionable steps to continuously improve.

Speaking of continuous improvement — we just released a few updates to the Dartboard. Now you can see a more detailed Dartboard report, facilitate a productive team discussion with our downloadable guide, and create your own follow-up assessments — which is critical to team success! Continue reading …

I procrastinate. In high school it was a huge issue for me, because as a high schooler I was still inexperienced at it. I frequently found myself in last-minute mode, moving swiftly from one self-induced crisis to another.

College wasn’t any better. The assignments were more spread out, but the due dates tended to be final due dates, whereas in high school there were usually several interim deadlines for milestones. Continue reading …