Epics and Outcomes

When teams are first moving away from, “Epic is a container for a list of features,” and towards, “Epic is a discrete investment decision,” It can be hard to reorient. In their old world, the epic had some sort of field – “list the features contained in this epic” which was straightforward to fill out. The decisions they made were really easy: “Is anything we planned to build missing? Add it.”

When your mental model is, “We need to predictably deliver all these things someone else thought was important,” managing the flow of epics is pretty easy. Creating a ‘roadmap’ is easy too (hint: it is not a roadmap, it is a release plan, with the features grouped together conveniently for making a pretty presentation).

And this is why it is hard for teams to reframe. We are asking them to stop doing the easy thing and start doing the important thing. Set aside, for the moment, the challenges of creating the conditions in the organization where this team (the portfolio team) is allowed to do important work – this is what we do at LeadingAgile, removing all of the barriers – I want to focus on the shift in thinking that has to happen. We put the structures in place which allow the practices to flourish that embody these changes.  

How we structure the epic is as important as how we structure the teams and how we structure the flow of work. All of it is needed.

The epic contains two key fields – the desired outcome and the success criteria. The names of these fields could be different – they could be “lagging indicator” (relative to the lifecycle of the epic) and “leading indicator.” You could also call them “benefit” and “KPI.”

The elements of the epic need to support the decisions we make within and about the epic. I think of the first set of questions together – “Should we do this?” “When should we do this?” “What cost should we be willing to incur in order to do this?” The primary element of the epic needed to answer these questions is the desired outcome field. This field is where the team articulates the benefit which justifies the investment and decisions about when to invest. This information is a focal point for collaboration within the portfolio team (and occasionally across portfolio teams).

This benefit-realization expectation is also the critical element to assuring coherence between the scope of work we are about to undertake, and the level of ambition embodied in the strategic plan. All necessary cross-team collaboration to assure the capacity of the teams is allocated to effectively execute the strategy. I often talk about this as “collaborating up.”

The second set of decisions we need to make – and this is where the conceptual shift is hardest – are captured with “What do we need to build to achieve this outcome?” This is a key difference between business Agility and just another feature factory faux-Agile farce. We are asking the portfolio team to be responsible (in collaboration with the product teams) for making the right choices about what things should be built to achieve the desired outcomes – taking into account organizational capacity (balancing capacity with demand) and dependencies and impediments; broadly assuring feasibility of the approach.  

To support these decisions, a desired outcome is operationally too abstract. We need a causal linkage between what we choose to do and why we choose to do it. Half of this causal linkage is embodied in an outcome hypothesis.

We believe if we cause these (observable, measurable) behavior changes (or KPI changes) in the system, it will result in realizing the desired outcome (benefit) we intend. We will know we are right if we see (measurable criteria) and we will know we are wrong if we see (measurable criteria).

The mindset shifts to embrace uncertainty and think of the approach to executing each epic as “placing a bet” is again, literally, what it means to embody business agility. We are starting with the assumption we may be wrong – which makes it possible to learn you may have been wrong. If you are already certain about what needs to be built, you will never give yourself the opportunity to discover how you are wrong.  

The other half of this causal linkage is captured in a solution hypothesis.

We believe if we build these (features), they will solve these problems resulting in these (observable, measurable) behavior changes. We will know we are right if we see (measurable criteria) and will know we are wrong if we see (measurable criteria).

The solution approach – which features – is referenced from the epic but is not included within the epic. This is a conceptually different place. The epic is where we center the outcome hypothesis;  the solution design work – typically across multiple features – is where we embody the solution hypothesis.

For the epic to contain both halves of the outcome hypothesis (the change we are trying to create, and how we expect to benefit if we create it) – we need two fields. The success criteria field is where we capture the intended changes to the system. We separate the fields because we are introducing new behaviors and new frames of reasoning and decision making. The product team(s) who are responsible for developing the solution approaches need an anchor – the success criteria. We only ask them to abstractly shift their thinking into one hypothesis – the solution hypothesis – and to partner with the portfolio team who anchors on the outcome-hypothesis.

Through a quantified success criterion, an epic provides the structure to enable the product teams to explore options for how best to solve the problems which (we believe) we need to solve to achieve the measurable change in behavior.  The portfolio team collaborates with the product team to come up with solution approaches that are both right alone AND right together. I refer to this as “collaborating down” when working with portfolio teams, and “collaborating up” when working with product teams.

This is a radically different set of expectations for the members of the portfolio team – to elicit, define, align upon the intended outcomes; assure their coherence with strategic intent; provide clarity of purpose to the product and delivery teams. It was much easier when they only had to ask, “do you want fries with that” and pass the order on back to the kitchen staff.