Options for “splitting” a Story that is too large to deliver within a Sprint?

Ideally, while drafting and finalizing an Epic (Lean-Agile Business Case) and deriving the “minimum viable release” that corresponds with delivering the expected value towards strategic validation, we’d inherently find the most focused, user-valuable delivery plan.   

In the early days of scaled agile adoption however, this will prove difficult to learn.   As a result, we’ll likely have some Stories larger than we’d prefer.  

A good size USER story requires a few members of the team approximately 2 to 4 days to deliver (elapsed time, not necessarily ‘effort’).   This includes cohesive skill and effort to Analyze, explore solution options and choose a preferred approach, Design, Change the [Service, Software, Call Center Scripts, Training, etc.] Solution, Deploy the solution, and Validate the solution.   

Note:  This likely doesn’t include activities for “going live in production” for the first few fiscal quarters.   It takes time to optimize the ability to deploy “dark releases”.   See related discussion here [link to be added].

So, here’s a visual aid to assist Product Owners, System Architects, and Team members as they [in a less ideal manner for now] find a way to divide the work up for better incremental delivery and closure.

A visual guide:  ​pdf icon Story-Splitting-Flowchart.pdf

*observe in Step 2, the clock-wise approach to explore better options and how those options regress as we work our way around the wheel of options.

A helpful article:  https://www.businessanalysisexperts.com/splitting-user-stories-techniques/

This article offers nice examples to solidify understanding.

Your Value Stream coaches will explore these options in detail as part of the private Coaching Circle gatherings.

If ever confused and concerned about these ideas, please post comments and questions here.