Software is complex and the only way to manage the complexity is to divide and conquer — breaking up the system into smaller and smaller parts, and creating an environment where we can continuously deliver small increments of increasing value.

But. Because Software is complicated…it isn’t just the sum of the smaller parts. And it’s not uncommon to pull all the small parts together and find that it doesn’t look or work like what we had in mind.

Being able to see the big picture, breaking it down into smaller parts and then delivering these in a way that achieves the business goals — is the job of a product owner. It’s a big job and it needs to happen at multiple levels of granularity.

‍

Themes

Starting at the top, we have a product. Or, at least, we have a vision for a product. The diagram below represents this as a box, which we will start to divide up into smaller and smaller pieces.

To make the product easier to manage and to allow us to divide the work across multiple teams, we break it down into Themes.

In an ideal world, themes would be MECE (mutually exclusive and collectively exhaustive) but in reality there’s going to be plenty of overlap and integration.

Breaking down into themes helps us to focus on a smaller part of the product at any time — yet it could be fairly high level i.e. Mobile App, Cloud App, API, Services.

‍

Objectives

When deciding what to build next (i.e. the roadmap) we’re driven by the goals of the business and user — and these are defined as Objectives.

Objectives need to be measurable otherwise — how do we know when we’ve achieved them? They also need to provide some real context about what we’re doing and why. A great size for an objective would be something we can achieve in 1–3 months.

The most common reason for a software product failing is because the wrong thing is built. We’re in the business of solving problems and this means taking good ideas and turning them into software. But often good ideas aren’t the right ideas or the most important ideas.

And because there’ll always be hundreds of good ideas, we need an objective so we can test each idea against whether it will move us toward meeting our objective — or not.

Not all objectives are equal and they don’t cleanly fall within a single theme (although sometimes they do). But it’s through objectives that the business will express their priorities and goals in three ways:

‍

1. Metric Based Objectives eg. Increase the conversion rate to 20%. In this case we would need to experiment and measure to reach the goal.

2. Outcome Based Objectives eg. A mobile app that allows you to place an order. This would give us the freedom to design and plan how to achieve the outcome.

3. Feature Based Objectives eg. A specific feature or enhancement (often v1). Here we would need to understand why (the objective) and how we’ll measure — and know when we’ve achieved it (the key results).

Epics

To achieve an objective, we need to break the software down into a set of smaller steps or increments called Epics.

Usually, an epic is a single deliverable. It might be a feature or a new screen or a report. It is at this level of granularity that most discussion between the product team and the business (or the customer) will happen.

User Stories

When the product team are ready to deliver an Epic, it will be broken down further into a collection of User Stories — which can be estimated, made sprint ready and delivered.

Because the purpose of a User Story is to communicate between the business, users and product team, we need to think about the communication at two levels:

1. The story is a discrete piece of work that must make sense in isolation
2. The story exists within a larger context, to achieve an objective and as part of an epic

The User Story is broken down even further by defining Acceptance Criteria and Tasks.

This is the level of granularity that the product team is operating at, but it’s often too much information for the business.

If we don’t have a clear relationship between the Epics and the Tasks via user stories, then the product team and the business can easily get out of sync.

A note about Budget: Typically if a budget constraint is going to apply, it will apply to the epic. Yet when the epic is broken down into user stories, the estimates on each user story will often add up to more than the budget. In situations where the epic has been time-boxed like this, we need to prioritise the user stories and understand which ones can be delivered within the budget and communicate this to the business. There will always be low priority user stories that can’t be done within the budget. This is an example of the business thinking in epics — I want this feature and I have this budget. The product owner needs to translate this into prioritised user stories that will achieve the epic within the budget. The product team needs to stop complaining that they haven’t been given enough time/budget to deliver all of the user stories and start focusing on how they can best achieve the objective and deliver the epic.

‍

There will be gaps

This brings us to the key point of this blog post— there are always going to be gaps between User Stories within an Epic and between Epics.

These gaps, which often aren’t visible until the User Stories are completed are often given the badge “bugs”.

The product team and the product owner are going to work hard to minimise the gaps — but as a rule of thumb, to reduce the gaps you need to reduce your granularity — imagine trying to minimise the gaps within a jar of rocks — vs a jar of pebbles vs a jar of sand.

As you get more and more granular, you will find yourself doing significantly more up-front planning and writing documentation and your cost of development will be higher. This isn’t to say that this bad, just be aware of how granular you want to go and if you choose not to fill the gaps up-front, then you will fill them in later.

‍

In a lean environment, our goal is to deliver value Epic by Epic as we work toward achieving the objective. This allows us to measure and learn as we go, see gaps sooner and be able to prioritise the remaining work.

It also means we can measure the objective and stop as soon as we are happy that the objective is achieved (often even 80% achieved would be a great outcome and a great time to stop). It’s a natural part of this process to see the gaps as we go and fold that new knowledge back into the backlog as we prioritise filling the gaps with the next Epics.

These different levels of granularity explains the difference in perspective between the business and the product team. The business is looking at Objectives that will be delivered through an agreed set of Epics. The product team is working with User Stories that must meet the Acceptance Criteria. When the business sees an epic released from the product team, they immediately see the Gaps.

When we’re creating Software-as-a-Service, we’re not just building software — we’re building a business. It’s a combination of industry and domain knowledge of the business and software product development and operational knowledge of the product team.

At EndGame, we like to take a long-term approach to all products we work on. Because we aren’t just building shiny new apps — we’re working hand-in-hand with our customers to deliver on their objectives.

We’re also working to ensure each Epic has a defined value and, as a single team, we can all understand the big picture and make sure we’re finding and filling the gaps together.

And that’s only possible through relationship and teamwork — not process and documentation. Which is what Agile software is all about.

‍

A word of warning to product teams‍

‍ It’s the gaps that define you.

You need to understand the context of everything you do: Acceptance Criteria serve a User Story. User Stories serve an Epic. Epics serve an objective. And objectives serve the business and the customers.

Never take a User Story without its context, because then you’ll be blind to the gaps and that can make you look incompetent.

‍

A word of warning to the business

The gaps are going to be there until you see them and fill them

It can be hard for the business (or customer) to get their head around the granularity needed to build software. But if you don’t put the work in up front to find and fill gaps during the planning and design — then you should expect to find them once the software is built. That is simply just part of the process. So be prepared to iterate on the product to fill the gaps. If you’re not happy with the gaps, you need to put in more effort up front to fill them.

‍