Epic slicing patterns

Even if Agile is widely implemented on the team level, many organizations retain their culture of preparation. Doing preparations is a habit that lulls security and makes people believe estimates and solution choices are accurate. The estimated data is then used for planning and reporting to the management who make the appropriate decisions. Then the Agile teams are expected to slice the backlog and deliver the solution in small valuable increments.

Some sources, even Scaled Agile inc, refer to Epics as “large initiatives.”

This is a struggle for the Agile teams. The solution is already fixed, many initiatives must be worked on simultaneously, deadlines are promised, and experts are stuck with analysis. These and many other obstacles destroy the creative power in a team setup. Everyone knows this is not an ideal way of working because it is obviously not much different than what we used to do. The queues are still long, and the quality is not getting better. The positive side is that the problem is now clearer, and we have teams prepared to take responsibility.

The major challenge is to let go of too rigid planning. To accept the uncertainty and instead implement the Lean-Agile mindset also when preparing and prioritizing large initiatives. Difficult? Of course, it isn't easy, but without ambition and courage, it will never happen.

Try to resist the following thinking:

• We better get everything done while we are at it.

• We cannot get all of the business value before we have done the entire thing.

• Before we start, we need to make sure we understand all of it.

• We will avoid surprises if experts investigate everything before we start.

• Management is responsible and needs a well-prepared decision basis for large investments.

Instead, promote the following thinking:

• The faster we can deliver, the faster we get valuable learning.

• Large things are more complex than small, and complexity is evil.

• It hurts less when failing with something small.

• Decisions about small things are easier to delegate to people closer to the business.

• It is much more productive to have a flow of small things than working in parallel on large things.

• With small and frequent deliveries, people get more engaged, and their creative contribution will positively impact.

To get going, guiding patterns can be beneficial. Many teams use the ten slicing patterns included in the white paper “A User initiative Primer.” These patterns can inspire at any level of a product backlog breakdown, and the adoption in this article is intended to show how slicing can also be applied to the first Epic creation moment. It is best to have the white paper in front of you and compare patterns used to slice features into stories.

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.

I have found the following patterns useful when slicing large business or regulatory initiatives. The examples mentioned below are just of way to think and not always the absolute best way to handle this break-down. Only you know the prerequisite of your organization and can find the optimal slices. Avoid user experience and, instead, aim for organizational capability or business functionality.

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. We are only looking 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 simpler 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.

3. Major Effort

Sometimes an initiative can be split into several parts where you guess most of the effort will implement the first part. In the example shown below, processing infrastructure should be built to support the first initiative. Adding more functionality should be relatively trivial later on.

4. Simple/Complex

When your organization discusses an initiative, and the initiative 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 its own initiative, and then break out other variations and complexities into their own initiatives.

Tip: Modularization is the best thinking pattern to reduce complexity. Components with purpose and a defined interface are usually clean-cut that can 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 simplest version. An example of where different purposes and sources have been used here.

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.

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 base
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.”

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. In the GDPR-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.

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.

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 no exact rule for slicing the backlog, but aid in finding alternative ways of thinking. You may end up slicing 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 slicing 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 detailed specifications or regulations. Instead, discuss the impact on your business and then slice 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 slicing 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. The habitual culture

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

If