2♀ + 3♂ + 1♀ By Sascha Kohlmann | CC By 2.0
Every function within an organization has its own vernacular. Marketing talks about conversions, leads, MQLs, and SQLs. Sales talks about pipeline, qualified leads, prospects, and revenue.
Product management and engineering are no exception. In this post, I will highlight a few of the most commonly used (and misunderstood) terms so that you can understand and better communicate with the technical teams that use them on a daily basis.
The following represents our classification system for the “kinds of work” that we perform. Note that other companies have similar (and in some cases, many more) terms; we find that these terms encompass nearly every scenario we encounter.
Feature – This refers to a wholly new set of capabilities that are being built into the system. For example, we categorized Collections, which allows users to create their own ‘playlist’ of content, as a feature.
Improvement – When we make incremental improvements to a feature, we call this an Improvement. For example, when we first rolled out Collections, users could not reorder items within them. Within a month of that initial release, we released an improvement that allowed users to reorder the content assets within their Collections.
Bug – This means that something is not working like it should; that the expected output didn’t match the actual output. If it turns out that the expected output and actual output originally matched but then broke later, we may call that a regression.
Task – Tasks are usually pieces of work that need to be done, but don’t necessarily result in a direct benefit for the user. For example: Purging old, deleted files from our storage system is a task.
Epic – When a feature has many, many parts to it, we organize them into an Epic. The Epic serves as a the container for a lot of features and tasks that make up a complex new capability.
Maintenance – When we perform maintenance tasks on existing code, this usually results in behind-the-scenes code changes that result in no impact to the customer. Often this is also referred to as refactoring.
There are also different ways to describe the “resolution” of these pieces of work:
Fixed – The work was finished and tested by the engineering team member.
Resolved – The testing team has validated that the fix works as expected and causes no adverse effects elsewhere in the system.
Closed – The work was pushed to production, and now all users can experience the benefits of this work.
Duplicate – Oops! The ticket that describes this work’s primary purpose is already covered in another ticket.
Accidentally fixed – In the process of releasing another piece of work, a fix was applied. This results in the satisfaction of closing a ticket without actually having to do any work to resolve it.
Outlived – When a ticket has been around so long that the underlying need is no longer there, we close the ticket and mark it as outlived. It takes a combination of luck and skill to close tickets out as outlived.
While these core terms differ from company to company, I hope that they will help you understand the taxonomy that guides the work of product and engineering teams. Insights like these help foster improved communication and are the keys to effectively working together. As core internal groups work towards become as integrated and efficient as possible, we see the methodologies of one group influence the other. Ahem..agile development → agile marketing.
Did I miss any commonly used terms? Add them to the comments, along with their definitions.
Jason Shah
CTO
Jason Shah, a “Flyer” since 2010, is responsible for cutting-edge product development and engineering for the enterprise software company. His duties include overseeing all elements of product development, platform and integration engineering, platform security, customer delivery, and product marketing.
Comments are closed.