Agility Meets Process: How to Triage Requests to Effectively Manage a Sophisticated Suite of Products

This post continues to examine the processes in place at Tasktop to support its software delivery apparatus. Recall that Part I reviewed the quarterly cadence that Tasktop follows to ensure coordination across the entire organization, while Part II explored the feature request template Tasktop follows to ensure that its customers’ and partners’ highest-value requests get satisfied in a timely manner.

Today’s post explores what happens within the Product team once those requests are submitted, looking at the process that helps the Product team manage and provide visibility into the various product requests it receives. That process takes us from a backlog full of feature requests relating to one or more products, to nicely groomed, product-specific feature backlogs that are used to plan -- all the while maintaining visibility within the organization and enabling reports on certain key delivery metrics.

Challenges in a Changing Landscape

Since I joined Tasktop three-and-half years ago, its headcount has more than doubled, and the product landscape has grown dramatically. Behind our ability to integrate artifacts across disparate systems are a number of different components that facilitate the end-to-end flow. Internally, we think of these as products. In 2013, we had two main categories of products: the connectors, which allow us to communicate with each given repository we can integrate, and the core processing engine that processes what is being sent in by the connectors. We had a handful of connectors and one primary core processing product. Today, we have more than 50 connectors, which effectively amount to 50 mini-products within this product category alone.

One reason we’ve been able to increase our connector volume so quickly is our software development kit (SDK), which provides the standard to which all of our connectors conform. This is important so that each works as reliably and consistently as it can, given what the end-system permits. The SDK itself is managed like its own product with user-facing features and falls under a new category of product that we manage: our internal tools.

Also in the internal tools category is the system we use to manage all of the information about the connectors, such as a list of supported versions of each repository and artifacts within those repositories. This is yet another component that we manage as a product.

Finally, we have the core processing products that utilize all of the SDK-backed connectors. In the past, Tasktop Sync was our primary core processing engine, and over the last few years, we released additional styles of integration. All of that has culminated in our recent launch of the Tasktop Integration Hub, which makes all styles of integration previously supported available in an intuitive web-based, consistent user interface.

Evolution of the Triage Process

Likewise, our triage process, which had simple roots, has had to evolve to become robust enough to meet the complexity that comes with rapid growth.

The first step in establishing our triage process was to identify the right tool to use for managing request submission and feature backlog. In the past, we used the same Agile management tool our developers use to manage their work, but this didn’t satisfy the need to have different views into the same data. And it wasn’t effective once we began to see some of the growth described above. After some analysis, we decided to use a tool called TargetProcess.

With TargetProcess, we have boards set up that help move us from requests to features to a release plan for each team every quarter. Initially, having a single request board to show each request by state and a feature board for each team was sufficient. Over time, though, we’ve expanded such that we have a series of boards relating to both requests and features and a workflow to help us with the full triage and planning process.

Triaging to Manage Incoming Requests

On the request side, we have a starting board that shows us new requests that have come in that haven’t been reviewed by anyone. From these boards, we take steps to represent that request accordingly: we first check to see if there’s already a feature relating to that request and, if so, link them. If there is no feature that already exists and if the request is straightforward we can create a feature from there. If the request and/or resulting feature is unclear, we move it into a discussion phase to get more information from the requester and/or to discuss it with UX and the development team to identify the right solution.

On the feature side, several boards help us plan and execute releases. A series of them provide visibility into backlogs and release plans by team and product. Each product manager has the flexibility to create boards that suit his or her own needs. For instance, as product manager for the Tasktop Integration Hub, I’ve set up views to see features grouped by their higher-level epic, which can help to set the thematic focus for a given release by enabling me to look at all the gaps in a given feature area of the product.

The process allows us to manage all incoming requests across the projects, make sense of them, and update the feature backlog accordingly. This alone, however, wouldn’t make our triage process complete. Equally important to the mere act of managing the requests is providing visibility into what has been submitted.

Triaging to Provide Visibility

The established triaging process provides visibility into where a given request stands and ensures and demonstrates our responsiveness to customers and partners. It accomplishes this because the in-depth triaging also involves adding the right metadata to our request fields, derived from what the requester specified as part of the request template, such as the customer and level of urgency.

The Level of Urgency field helps us to know how quickly a given feature might be needed so that we can tend to those first.

The status of a submitted request also provides visibility for the submitters. The various closed states, Closed (Final Decision), Closed (Duplicate), or Closed (Functionality Exists), quickly tell a submitter where the request stands. Anything in Stakeholder Ranking Phase means that there is a feature on the backlog for it, but that the feature has yet to be planned. Anything in Tentatively Planned means that the resulting feature is slated for a given release. And something marked Partially Implemented or Fully Implemented denotes that some or all of the resulting feature(s) are accomplished.

Recent activity boards allow people to see which requests were submitted in the last few weeks, and which new features were created. They also allow people to see which features are active and have had comments or attachments added to them.

The customer tags also help us know which requests were driven by a particular customer or partner. This information gets transmitted to any features resulting from a given request, helping us make decisions when release planning. These features help us involve the field more in the planning process by doing things like soliciting input from Buy a Feature sessions.

Of course, having a backlog of features that we use in planning means that once we’ve identified goals for a release we can synchronize those features into the developer’s tool so that they have visibility into what we’re building and we on the product team can follow the status of those features in our own tool.

When a given release wraps up, customer tags that get transmitted to features tell us to follow-up with each to let them know we’ve satisfied their request.

We also have a series of reporting boards that show what each team has delivered each release, and also what has been added to each product as a whole each release. And from all of those completed features, we have boards that reveal how many of those features were customer or partner driven, which were fast-tracked (meaning we had to adjust the original release plan to get them in), and how many features we included to satisfy high-level urgency requests. All of these work to show how responsive we as an organization are to our customers’ and partners’ needs.

The triage process we have in place is just that—a process. In this case again, however, we’ve found it helps our product team function efficiently and effectively by acting as the main conduit through which all needs are voiced and all feature requests flow. The process helps satisfy customers and partners by ensuring their needs are well represented, keeps our internal field team happy by giving them adequate visibility into where things stand, and provides the product team with a way to create order.

Tips

Over time, we’ve adjusted our triage process to create more sophisticated flows to help manage the incoming requests and resulting features and provide visibility within the company into those items that have been submitted. Here are some tips to help your product team do the same:

• Recognize that tooling is important—just as developers and testers have their preferred tool to manage their work, PMs should have a tool that meets their needs around managing incoming requests and planning releases.
• Ask submitters for the right metadata with each request they send in, and record it in a way that can inform planning and help you provide visibility over time.
• When triaging, make sure you understand what the business need is, rather than relying only on what the submitter says. Indeed, oftentimes rather than describing the problem, submitters will prescribe a solution. But it’s your job as PM to make sure the best solution is identified to meet the need.
• Different “discuss” states for requests can inform you which requests require additional information, and which member of the development team needs to weigh in to help determine the best resulting feature.
• Ideally, assign one product manager to manage each product backlog.