Agile teams have been working on their Product Backlog quality for quite some time. The best guidelines for splitting User Stories have been around for more than ten years:
While there is much experience on the team level, many organizations retain their culture of preparation. The preparation is needed to feel secure in estimating the work efforts and choosing a technical solution. 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.
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 more clear, 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 is difficult, but without ambition and courage, it will never happen. To get going, guiding patterns can be very useful. Many teams have 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.
It is very common that regulations become large initiatives in organizationsmanagement, who usually owns the top of the backlog, has some work to do. I do think it is time to start splitting backlogs into smaller items at all levels. It is not much different on whichever level you work on. A uniform handling of the backlog will create higher throughput and faster feedback.
I have found the guidelines for splitting User Stories useful also when splitting large business or regulatory Epics. In this article, I have adapted the well-known patterns to give inspiration for the splitting of Epics. I choose to use the word Epic since it seems to be the most popular name for high-level backlog items.
How Small?
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.
Every type of business has different demands, but lead-time should not be longer than your competitor's. Most companies want to be faster than six months, which is a long time to get feedback from customers and the organization. On the short side, make it as fast as possible. A two-week Epic would be nice.
Which Pattern to Use
You’ll often find that you can split an Epic using several of the patterns. Do not aim for the perfect choice and do not regard these patterns as rules, but help find alternative ways of thinking. Sometimes you can use a combination of patterns, and sometimes you discover new patterns. Start with something, get going, and learn.
On this level, avoid user experience; instead, aim for organizational capability or business functionality. Design details and solutions will have to come later when the Epics are broken down and getting implemented.
A regulatory example
Commonly, regulations become large Epics. These initiatives are “mandatory” and have a strict deadline. The regulations are thoroughly specified and can easily be thought of as a become big-bang implementationimplementations. 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 slicessplitting patterns.
Regulatory directives are not only thoroughly specified, but they are also well structured. It means you do not have to become a legal expert to understand that the legislator has already thought of a rough implementation. For example, there are in many cases requirements for a register that may be implemented as one separate deliverable. Of course, you need legal experts, but instead of pre-analyzing everything, they should get involved in properly delivering small parts like the register.
When splitting business Epics, it works in the same way. Do not ask your experts to pre-analyze everything. Use these patterns, find the deliverables, and involve the experts in properly delivering the small parts.
1. Workflow Steps
Identify steps or sub-processes that will occur in sequence within your organization, specified in or influenced by new the requirements, and then define these steps as separate incremental initiativesEpics.
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 initiativeEpic, especially regulatory, have plenty of rules, this pattern is obviousevident. Some rules are more complex or extensive and serve as a single initiativeEpic. Other simpler more straightforward rules may be grouped in clusters.
Seak Seek to find high-level rules you can understand from a business perspective. In this case, break down the initiative Epic into several initiatives Epics 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 some rules.
3. Major Effort
Sometimes an initiative Epic can be split into several parts where you guess most of the effort will go towards implementing is hiding in the first partone. In the
For example shown below, processing infrastructure should be built , awareness of where personal data is stored and the legal obligations are developed to support the first initiative. Adding more functionality should be relatively trivial later on.
As a user, I want to be able to select/change
my pricing program with my utility through
my web portal
...I want to Pre-pay for my energy
…I want to enroll in Critical-Peak-Pricing
Epic. The implementation of further Epics 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 discussing discusses an initiativeEpic, and the initiative 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 its own initiativea separate Epic, and then break out other variations and complexities into their own initiatives.
As a user, I basically want a fixed price, but
I also want to be notified of Critical-PeakPricing events.
critical peak pricing event
...respond to emergency events
into different Epics.
Our entire business must be GDPR-compliant from 25 May 2018
GDPR-compliance in the Value Stream “new emerging business”
GDPR-compliance in internal HR-systems
GDPR-compliance in Customer Relationship Systems
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 Epics just-in-time after building the simplest version. A localization example is shown here.
As a utility, I can send messages to
customers
...in Spanish
...in Arabic., etc
most straightforward version—an example of where different purposes and sources have been used here.
consumption
...in a comparison chart, so I can compare my
usage to those who have the same or similar
household demographics
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 usage communication rather than the functionality of a supporting systembusiness process. In that case, split the initiative Epic to build it with the simplest possible system support, while relying on
on UI and then build the richer UI later.
As a user, I can view my energy consumption
in various graphs
fundamental communication first and then advanced 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 in making it fast
– or reliable – or more precise – or more scalable. However, the team can learn there is a lot to learn from the basea 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 Epic into successive “ilities”“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 Epic covers multiple operations, which can offer offering a natural way to split the initiative.
Epic.
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, then the initiative Epic can often be split according to the individual scenarios of the use case.
10. Break Out a Spike
In some cases, an initiative may be too large or overly complex, or perhaps the implementation is poorly
understood. In that case, build a technical or functional spike to figure it out; then split the initiatives based on
that result.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 Epic 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, compare the usual and introvert assumption to the left with the alternative assumptions to the right.
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 Scrap the whole initiative, Epic or exclude some systems, departments, or other partitions of the Epic. 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 of 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 in 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 do 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. Always split by habit
This last pattern is a meta pattern that addresses culture and leadership. Management needs to be on the front line and show that flow and “optimal batch sizes” are essential. If management understands how splitting works and makes it a habit, the rest of the organization will follow.
If management says: “We know we must implement these regulatory requirements, so why bother to split it into separate Epics. Let’s decide and let the organization take care of it. Anyhow, we will not get the benefits until we are fully compliant.”
What are then the chances for the rest of the organization to split the backlog and delivering it piece by piece with quality?
References
Donald Reinertsen, Principles of Product Development Flow.