Outcomes are observable changes that drive business impacts and together define our success as a company. Every unit of work in Echoes is annotated with its intended business outcome, which makes the configuration and grooming of the outcomes relevant to your business crucial to the quality of the data you collect.
Outcomes in Echoes are defined as a tree: the deeper in the tree, the more specific the outcome. No elements of the tree are fixed: outcomes can and should be customized to account for the specificity of your business. If you already use , follow or any similar framework, you already have a good sense of the measurable outcomes that matter to your business and should reuse those.
- Good outcomes are concise and unambiguous, making it easy for technical teams to accurately express the intent of their efforts.
- Good outcomes speak to everyone, making it easy for non-technical stakeholders to understand the purpose of work.
- Good outcomes should be measurable but don't need to be measured to be used for reporting.
- If a given aspect of the work is better defined as a time-bound shared effort than an outcome, such as a project a program, are likely a better fit.
Echoes comes with a default for intended outcomes.
The default set have been chosen to be applicable to most engineering organizations, but naturally are specific to none. For example:
- Customer value may capture all the work directly visible to your users, either through delivering features, bugfixes, or improvements.
- Risk mitigation may capture the obvious such as legal compliance, or fixing security issues, as well as the commonly invisible work of updating obsolete dependencies.
- Throughput may capture the work we put into automation, refactoring, testing, and all of these things that make software development sustainable.
The default outcomes were deliberately phrased as positives.
There are many different ways to customize the outcomes, and no good or bad answer: it's all a matter of capturing what is valuable to your organization. In this section, we will only give a couple of hints inspired by real world usage of our customers.
- Mapping OKR to Echoes outcomes. OKRs are a natural fit to use as they already are a universal language for the company. One key thing to keep in mind here is that while most engineering efforts contribute to OKRs, not all of engineering work does. It is recommended when mapping your OKRs into Echoes to preserve a space for things unrelated to an objective. See our more complete guide on .
- Expanding on the default set. Many customers start with the default set, and progressively are more specific about the things they intend to track. For example, we might see "Acquisition" under "Customer value" as to capture changes specifically intended at acquiring new customers.
- Starting from scratch. We have seen customers interested to identify the share of work that was planned versus the work that wasn't planned (e.g., arising for customer calls or sales requests). We have also seen customers interested to identify the work originating from internal feedback (e.g., QA or product reviews) versus external users feedback.
Again, there is no good or bad answers there, it's all about what makes sense for your particular context. See our for more practical examples, and let us know if we can help you get started!
Of course! It is very much expected that your intents will evolve over time. Removing an outcome will make its corresponding labels disappear in integrations (making it impossible to annotate new work items with this outcome), but the annotation of past work with will not be lost and continue to appear in the reports.