Writing Outcomes to Drive Epics

This is part 2 of Why Agile fail. Part one is here >>>>

Let’s start with the outcome

We all use the term Epic to mean a higher level outcome, Unfortunately we don’t agree on what an epic actually is. For many, an epic is the same as an old fashion project. This may be convenient for Portfolio Management, but as many projects last for months, keeping an epic alive for such a long time negatively impacts agile delivery and effectively removes a tier from our story breakdown. Long term projects are also an anti-pattern in agile, where delivering value to the customer and responding to change is preferred over comprehensive documentation and long term plans.

So, if an epic isn’t a project, what is it? How do we turn a jelly-word into something with substance? This is done by tying the epic to a real thing. This is best done by making an epic a Customer Outcome. I will be covering customer outcomes in more detail in another blog, so for now, we can define an outcome is something that is meaningful to a customer, has a concrete content and offers business value. What it isn’t is a solution. So, going back to our mythical, but all to real, company, how would taking an outcome approach help? The Product Owner starts with a simple sentence:

We believe that we can increase the number of successful prospect conversions in the Sales team by increasing the number of phone numbers captured as leads on our website.

Validating the outcome

This is the Epic. An epic is strictly customer facing. Importantly, there is no technology in an epic. Epics can be of any length, though I’ve been more successful when limiting an epic to no more than eight weeks. A relative short time-box is helpful to ensure that team is able to understand the complexity of the epic, that it can be delivered quickly and that if an epic fails, there isn’t a large investment to write off. Epics may be connected together in themes, initiatives or old fashioned projects. As the higher level connectivity between epics isn’t really important to the team, being more of a vehicle for stakeholder reporting, then it really doesn’t matter what term you use. Epics also opens the door for experimentation.

Going back to the outcome, the first question it begs is how do we turn a belief into an objective measure? What is the lag metric that will indicate success or failure? For this outcome, it is the number of successful prospect conversions by the Sales team. Right away the Product Owner can establish a baseline. However, that metric isn’t enough. The number of conversions isn’t the end goal, that is the value of each conversion. Are all conversions the same, maybe leads generated from the website have a lower average order value to a lead found through cold calling? By taking this approach the Product Owner can define some financial models that can help put a value on the epic. At this point a call can be made to even start the epic in the delivery team.

The Product Owner now has a number of models, some of which make a valuable hypothesis. The team now needs to test the hypothesis. The Product Owner meets with the team, and they decide on the first User Story which forms an experiment. This is where the much misused Minimal Viable Product (MVP) comes into the discussion.

Before we go on, let’s take a second to talk about User Stories. Epics are decomposed into User Stories. I have had much success in defining the user story as exactly one path though the outcome for a customer. This approach will be familiar as scenarios to those who practice Behavioural Driven Design (BDD). Breaking the story into scenarios helps the team identify the good happy and exception paths. It also can help the team understand where dependencies on other teams and systems may lie. Most important, User stories, are not technical. They focus on the user’s journey through the system.

As the team are working on the MVP in order to test the hypothesis, the aim is to release the minimum code. The User Story in this case is

As a prospective customer, I enter my phone into the web site so that I can receive a call back from the sales team and place an order.

Scenario 1: Prospect successfully completes the lead capture page

• GIVEN the prospect is on the capture details page
• WHEN he enters his phone number and other details
• THEN the phone number is stored in a log file
• AND at the end of the day
• THEN the log file with the phone numbers is emailed to the sales team
• AND next day when the previous day’s leads are followed up
• THEN the sales team uses the phone number first before the email

Here you can see that with a minimal coding effort, a process has been put in place that can prove out of the work is worthwhile. There is coding required though to extend the lead capture page. This work is captured as tasks on the story. Tasks are technical, they describe the work that the engineers need to do to develop the story. They are complete, once all the tasks are finished, then the story can continue. Not all tasks are coding, maybe release notes need to be written or a SOP needs to be updated. By listing all tasks on the ticket the we get to a place of honesty. No one is confused as to what needs to happen in order to get this story out into production.

For sure, the story being delivered isn’t a long term solution, but it is the MVP. It provides a way to get to a decision on value using proper metrics and to validate the financial models of the PO. The outcome of this experiment is a clear understanding on the RoI for the feature. At this point everyone is on board with facts, not opinion.

What is important to call out at this point is the way the technology delivery team and the business team worked together. A small amount of code, having to be flexible in receiving the emails, and some manual updating by the sales team has been needed. One team supported the other as the outcome benefits both. The Product Owner has not had to climb hierarchies, or to ask for work to be done off the side of the desk. The moment a manager places a barrier between the delivery and the business teams, the company loses flexibility and openness. No one wants to battle at work. Given the choice of fighting a department manager or doing the easy but wrong thing, a team will do the wrong thing every day.

Implementing the real solution

The MVP has proved successful, and the combined business and delivery team has proven that adding the phone number to the page increases lead conversion. The delivery team is now responsible for implementing a more efficient solution. The best bit is at this point there is a working solution, but it has incurred technical debt. The currency of technical debt is time. In this case, a less efficient system that uses humans in places that an automated system would be cheaper was adopted in order to test the hypothesis sooner. Just because it is technical debt doesn’t intrinsically make it bad, more often than not it makes it less efficient. It is a business decision as to whether the more efficient solution is worth the cost of paying down the debt.

In this case, the business and delivery teams agree that the repayment is worthwhile. The delivery team meet and refine the epic via creation of user stories. At this meeting the team endeavour to identify all the user stories and express them as BDD scenarios.

Even a simple epic like this one, the addition of a text box for a phone number, has several stories:

• As a prospective customer, I enter my correctly formatted and regionally valid phone into the web site so that I can receive a call back from the sales team within 2 hours and place an order.
• As a prospective customer, I enter an incorrectly formatted phone into the web site and I am corrected as I type the number
• As a prospective customer, I enter a phone number that is not a UK valid and I get corrected as I type the number
• As a prospective customer, I am only able to enter 0–9, ‘+’, ‘*’ and a space to ensure I have the best chance of entering a valid number.
• As a prospective customer, I….

Even a simple epic like this one has interesting questions to ask. How doe the team want the input to work for the user? Should the international code be pre-populated? During this session the UX expert can help make good decisions on the experience. In addition the team can identify a number of experiments they can run on the page. Coming out of this session will be the wireframes for the experience and some of the technical tasks that will need to be completed.

Generally, for every decision the customer makes, the number of stories increases. It is at this point that many teams fail and start to fall apart. Working out the stories is hard work. the team needs to think through the customer journey. They need to map out the decision points. They need to challenge every additional user interaction as it adds more stories. The Product Owner needs to provide the value of each decision, what is the data that backs up the decision? How does the decision help achieve the business benefit of the outcome? Even simple epics can have numerous stories.

If story creation is so hard, why do it? If the team is going to deliver the outcome they are going to have to the breakdown at some point as the code needs to be written. However, if this breakdown is done in an ad-hoc way without upfront planning, the complexity of the outcome is never evaluated as a whole. How does anyone know when the outcome will be delivered? How do they know what to test? How do they change their minds if they find a problem weeks into development? Inadequate breakdown of the epic to stories is the number one reason teams fail to deliver value. I hope that at this point the value of keeping epics small can be seen in limiting the complexity of story breakdown.

Up to now nothing we have done is technical. It’s all about getting the customer interactions worked out. While it sounds complex, story breakdown is a real opportunity to have some team fun. Get up, move around, do a role play. Get the UX guys involved, the team want to be working through the storyboards, trying out the proposed UI, see if the stories make sense.

Stories are broken into technical tasks. My rule of thumb is that each task should not take more than two days to complete. The tasks may be writing code, they might be working on deployment environment, test, documentation, whatever. The definition of done for the story is when all the technical tasks are completed and the story is deployed into production. When working on new development, technical tasks only exist in context of a story. This is a critically important point. Too often teams have got lost in a maze of technical work without being clear on the outcome of the work.

Some technical tasks cannot be done by the team. In this example, the CRM team are required to enhance the API that is used to pass the prospect by adding the phone number. These technical tasks are added to the backlog of the other team, but held as dependencies on the story. In this way automatic reporting can generate the dependency tree and help manage the cross-teams expectations.

In conclusion

Too often Agile fails because the team have taken insufficient time to break down the work into customer outcomes and user stories. Without this up-front planning work, teams fall into ‘cowboy agile’, making it up as they go along, leading to lack of delivery and loss of confidence in the team. By taking the time to articulate the outcome and the stories, it is possible to share plans and build credibility with the business.

Find PArt 3 — Customer Outcomes, here >>>>