With reference to A User Story Primer, this is a further development that shows slicing can be applied also on the first Epic creation moment.Even if Agile is widely implemented 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…
It is very common that 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 specific steps that a user takes to accomplish a specific workflow and then implement the workflow in incremental stagesor 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.
2.
BusinessRule Variations
At first glance, some stories seem fairly simple. However, sometimes the business Since a large initiative, especially regulatory, have plenty of rules, this pattern is obvious. Some rules are more complex
or extensive than the first glance revealedor extensive and serve as a single initiative. Other simpler rules may be grouped in clusters.
Seak to find high-level rules you can understand from a business perspective. In this case, it might be useful to break down the story initiative into several
stories to handle the business rule complexityinitiatives to implement one at a time.
3. Major Effort
Sometimes a story an initiative can be split into several parts where you guess most of the effort will go towards implementing the
first onepart. In the example shown below, processing infrastructure should be built to support the first story;
adding initiative. Adding more functionality should be relatively trivial later on.
4. Simple/Complex
When the team is discussing a storyyour organization discussing an initiative, and the story initiative seems to be getting larger and larger (“what about x? -
have you considered y?”), and the path to an agreement is unclear, then stop and ask; “what’s the simplest thing that can possibly workour business could benefit from in this area?” Capture that
simple version as its own storyinitiative, and then break out all the other variations and complexities into their own
storiesinitiatives.
5. Variations in Data
Data variations and data sources are another source other factors of scope and complexity. Consider adding stories initiatives just-in-time after building the simplest version. A localization example is shown here.
6. Data Entry Methods
Sometimes complexity is in the user interface usage rather than the functionality itselfof a supporting system. In that case, split the story
initiative to build it with the simplest possible system support, while relying
on UI and then build the richer UI later.
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 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 story initiative into successive “ilities”.
8. Operations (example: Create Read Update Delete (CRUD))
Words like manage or control are a giveaway that the story initiative covers multiple operations, which can offer a natural way to split the storyinitiative.
9. Use Case Scenarios
If use cases have been developed to represent complex user-to-system or system-to-system interaction, then the story initiative can often be split according to the individual scenarios of the use case.
10. Break Out a Spike
In some cases, a story 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 stories initiatives based on
that result.
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 in the plan for decommissioning,
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.
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!