Level up your sprint planning with errors inbox

One of the most exciting things about being a developer is working on new, interesting features, but unfortunately, many developers spend the majority of their time responding to incidents and battling technical debt rather than writing new code.

At New Relic, our goal is to help you respond to issues quickly so you can focus on the work you love most. In this post, we’ll show you how to use errors inbox, workloads, CodeStream, and New Relic’s Jira integration to help prioritize, organize, and resolve errors and proactively improve the reliability of your system with each sprint cycle.

Step 1: Organize your architecture with workloads

Errors inbox offers a comprehensive view of all errors across your stack, gathering data from APM, browser, mobile, OpenTelemetry, and serverless sources into a single view. It then allows you to search, triage, assign, discuss, and resolve errors, all from one place.

This unified view makes errors inbox a useful tool to better visualize and organize your backlog in order to achieve more productive, data-driven sprint planning sessions. If you haven’t used errors inbox before, you first need to associate your errors inbox with workloads. When you first open errors inbox, you’ll see a screen that looks like this:

Workloads use tags to group entities that you want to monitor together. You can tag entities and then create workloads made up of these entities for things like your team’s tasks for a sprint, or specific tasks to be completed by an individual. You can set up your errors inbox at the workload level or the entity level using our scoped inbox feature to bypass setting up workloads. Workloads are defined with a simple dialog, and depend on your entities being tagged in order to group the entities into workloads. By applying different tags to your environment resources, you can create workloads that group them so they work best for your needs—such as workloads for your teams to manage sprints, or for engineers within your team to complete specific tasks. Learn more about setting up workloads.

On the top left of the errors inbox UI, there is a drop-down menu:

You can use this menu to choose the workload that you need. You can define new workloads from the same menu by using the Add new workload button. The default workload includes all of the entities in your environment. For small environments, this makes sense, but as you grow, you’ll probably want to segment your workloads.

Once you’ve defined your workloads, you can select View workloads from the workloads drop-down to see a high-level status of all workloads, which you can use for triaging and prioritization during sprints.

As the next image shows, you can get a high-level view of your workloads, which is useful for monitoring your systems and letting you know which areas are experiencing errors at a glance. You can quickly find which workloads need attention and assign them to engineers during a sprint planning meeting.

Step 2: Build a better backlog with errors inbox

Once you know which workloads have errors, it’s time to drill down so you can triage and assign those errors. From the main errors inbox page, select the appropriate workload from the top-left drop-down menu. New Relic will load all the errors that fit within the defined filters for that workload. By default, this means all unresolved errors for that workload.

The previous image shows currently unresolved errors sorted by the total number of occurrences in descending order. This application has a lot of errors, and some appear to be happening quite frequently. The first several errors should be assigned immediately, but to which engineers?

You can get more context by selecting an error. The next image shows the error detail page.

With this context, you have enough information to discuss the error during your sprint planning. You can see the impact of the error, as well as information on the stack trace, attributes collected with the error, and a visualization showing error frequency over time.

Step 3: Assign work to your teams

Once you’re ready to assign an error to an engineer or team, the error can be assigned directly from the error detail page.

If you’re using JIRA, you can use the JIRA integration with New Relic to create a JIRA issue without leaving errors inbox.

As a team, you can quickly identify the major errors that are affecting your areas of responsibility and then triage and assign them—again without leaving the errors inbox UI.

New Relic also stores links to your tickets alongside associated error groups for a period of time (around a year). If an error occurs again in that period, you can easily access associated tickets. For instance, you might want to assign a recurring error to the same engineer or team, or you might want to discuss troubleshooting steps your team has already taken to resolve the error.

Step 4: Take your planning into your IDE with CodeStream

You can also take your planning directly from errors inbox to your code base with the CodeStream extension for JetBrains, VSCode, and Visual Studio as well as the New Relic CodeStream integration. CodeStream helps you reduce context switching through integrations with the most popular developer tools, as well as gain easy access to error data that is automatically filtered to the code open on your screen which aids in troubleshooting critical errors.

When viewing an error that has a stack trace, you’ll see a Open in IDE button alongside the stack trace.

If you have installed the CodeStream extension in your IDE, and you have access to the repository for the code that is throwing exceptions into errors inbox, selecting that button will take you to the root of the error within your IDE. This integration makes it convenient for your team to quickly jump to the code with their assigned errors.