Patterns for splitting Epics

Ever since the knowledge about better ways of developing products started to roll out, Agile teams have been working on their Product Backlog quality. The best guidelines for splitting User Stories have been around for more than ten years.

• Ways to split User Stories by Lasse Koskela

• Patterns for Splitting User Stories by Richard Lawrence

• A User Story Primer by Dean Leffingwell.

The guidelines can be very beneficial, but it is still a struggle to succeed and change a tradition of activity-based planning in many organizations. However, Agile is becoming the mainstream, and User Stories has become the primary product backlog (PBI).

Everyone needs to be aware that larger PIBs should follow the same basic principle: it's not what we will do but what we want to have.

I have found the following patterns useful when splitting large business or regulatory initiatives. The examples mentioned below are one way to think; there may be another hundred. Only you know the prerequisite of your organization and can find the optimal split. Avoid user experience and, instead, aim for organizational capability or business functionality.

These patterns can inspire at any level of a product backlog breakdown, and the adoption in this article shows how the splitting patterns can be applied at the first Epic creation moment. It is best to have the white paper in front of you and compare the patterns to split a User Story.

How Small?
How small should stories be? I recommend 6-10 stories per iteration, so how small is small enough depends on your team’s velocity. Before your next planning meeting, calculate what estimate should trigger splitting a story. For most teams, it seems to be 8 or 13 points. But on a recent project, I’m doing it by myself, and I’ve needed to split 5-point stories.

Which Pattern to Use
You’ll often find that you can split a story using several of the patterns. Which split should you choose? I use two rules of thumb:

Choose the split that lets you deprioritize or throw away a story. The 80/20 principle says that most of the value of a user story comes from a small functionality share. When one split reveals low-value functionality and another doesn’t, it suggests that the latter split hides waste inside each small story. Go with the split that lets you throw away the low-value stuff.
Choose the split that gets you more equally sized small stories. The split that turns an 8 point story into four 2 point stories is more useful than producing a 5 and a 3. It gives the Product Owner more freedom to prioritize parts of the functionality separately.

Some sources, even Scaled Agile inc, refer to Epics as “large initiatives.” But think about the main idea to manage flow by optimizing batch sizes. Are Epics really an exception that cannot be small if needed? Of course not! The same logic is valid for all backlog items, regardless of who has ownership of them.

Commonly, regulations become large initiatives in organizations. These initiatives are “mandatory” and have a strict deadline. The regulations are thoroughly specified and can easily be thought of as a big bang implementation. I think you recognize the nature of such an initiative. I have chosen a well-known regulation called the General Data Protection Regulation (GDPR) as an example in the following breakdown.

1. Workflow Steps

Identify steps or sub-processes that will occur in sequence within your organization, specified in or influenced by new requirements, and then define these steps as separate incremental initiatives.

Tip: Do not make the mistake of using the sequence in your development process—first, analysis, then design, and so on. Only look at your operational value stream!

2. Rule Variations

Since a large initiative, especially regulatory, have plenty of rules, this pattern is obvious. Some rules are more complex or extensive and serve as a single initiative. Other more straightforward rules may be grouped in clusters.

Seek to find high-level rules you can understand from a business perspective. In this case, break down the initiative into several initiatives to implement one at a time.

Tip: Take the opportunity to assign business value to each rule, requirement, or type of information. Down prioritizing or even dismiss

3. Major Effort

Sometimes an initiative can be split into several parts where most of the effort is hiding in the first one.

For example, awareness of where personal data is stored and the legal obligations are developed to support the first initiative. The implementation of further initiatives should have much less uncertainty.

Tip: When talking about the effort, it is easy to break out technical infrastructure as one or several enablers. Enablers may be delivered first, as a kind platform, but are not used and evaluated until real usage in the operational value stream. Avoid enablers as far as possible. Instead, split Epics into something which can be used in your business.

4. Simple/Complex

When your organization discusses an initiative, and the solution seems to be getting larger and larger, and the path to an agreement is unclear, then stop and ask, “what’s the simplest thing that our business could benefit from in this area?” Capture that simple version as a separate initiative, and then break out other variations into different initiatives.

Tip: Modularization is the best thinking pattern to reduce complexity. Components with purpose and a defined interface are usually clean-cut that easily get acceptance.

5. Variations in Data

Data variations and data sources are other factors of scope and complexity. Consider adding initiatives just-in-time after building the most straightforward version—an example of where different purposes and sources have been used here.

Tip: Not all data may need to be real or updated in real-time. Early versions can thus use mocked, manually or seldom updated information.

6. Data Entry Methods

Sometimes complexity is in the communication rather than the business process. In that case, split the initiative to build it with the basic communication first and then richer alternatives to collect data.

Tip: Do not forget to involve the UX-people in the process of managing the backlog.

7. Defer System Qualities

Sometimes, the initial implementation isn’t all that hard, and the major part of the effort is making it fast
– or reliable – or more precise – or more scalable. However, the team can learn a lot from the basic
implementation, and it should have some value to a user who wouldn’t otherwise be able to do it all.

In this case, break the initiative into successive “ilities.”

Tip: Always work on the evolving Definition of Done. The best is to have an ongoing discussion of quality, responsibilities, and when a solution is finally delivered.

8. Business Operations

Words like manage or control are a giveaway that the initiative covers multiple operations, offering a natural way to split the initiative.

Tip: Think only about running the current business. When involving future business, it is easy to wind up into a meta-discussion and increase the delivery complexity. For example, operations of Product Development involves data of the employees, suppliers, or partners.

9. Business Use Case Scenarios

If use cases have been developed to represent complex user-to-system or system-to-system interaction, the initiative can often be split into individual use cases.

Tip: Do not Use Cases as a Carved in Stone approved requirement specification. When used as a creative tool in workshops, Uses Cases is fast and straightforward to create a mutual understanding.

10. Break Out a Minimum Viable Product (MVP)

In many cases, the market is uncertain, and it is hard to understand all parameters from a business perspective. Our instinct is to also deal with uncertainties regarding the ability to deliver the solution. On this level, however, we should only focus on the business perspective and assume that, in any case, we will be able to deliver a feasible solution. If an initiative gets prioritized, the teams will later have plenty of opportunities to deal with technical uncertainty through spikes and other measures.

When doing an MVP, start from an assumption and then develop a hypothesis validated through an experiment. Rather than just an experiment, an MVP and the Build-Measure-Learn concept is a scientific approach to understand the business priorities. To exemplify, the reader will find some alternative assumptions to the right. To compare with the usual and introvert assumption to the left.

Tip: The essence of experiments is to provide results quickly. It is a warning sign when it takes several weeks to get the result out of an MVP. Remember that “M” in MVP stands for “Minimum.” When coding is involved, there is a risk the meaning of “M” will change to “Maximum.”

11. Non-functional requirements

When there are plenty of legacy systems in an organization, a more radical pattern may be the most feasible. Simple, scrap the whole initiative or exclude some systems, departments, or other partitions. Maybe some systems are already in the plan for decommissioning. Is it worthwhile to invest in upgrading old systems or instead live the gap or advance retirement?

Remember that a pattern is not an exact rule for splitting the backlog but aid in finding alternative ways of thinking. You may end up breaking the backlog in a different way than you thought when starting working on a pattern, and that is OK.

In many cases, a combination of patterns is to recommend. For example,… To combine several splitting patterns is a pattern in itself.

Do not allocate people to do detailed initial studies. Dive into the summaries, often provided by authorities or even found on the internet, instead of reading exact specifications or regulations. Instead, discuss the impact on your business and then split your Epics and get started. Delivering is the action, and learning is the reward, whether you fail or not. Just make sure to fail safely!

To make the splitting work, you need to start delivering definitive solutions early and not wait until just before the deadline. Prioritize your learning. It is the main factor to enable delivery in time with the right quality.

12. Splitting is habitual

The most difficult is to avoid saying, “We know we must implement these regulatory requirements, so why to bother to split it into separate Epics. Let’s decide and let the organization take care of it.” It isn't easy because it is intuitive and normal to look at a large Epic as a monolith, which is best kept and will not create any benefits until fully accomplished.

If