Solution creation where stories do not conveniently map onto units of work or functionality

Have we lost our way?

You haven't mentioned Sprint Goals, or empirical process control, or increments or releases, or product complexity, or anything about work being "Done" each Sprint.

What outcomes do you expect to achieve through the use of Scrum, and how are you evidencing them?

Apologies, I think I made my question look bigger than it really is. My question was solely about our use of the intermediate 'model' document, which is created based on user stories. Then based on the model, we identify tasks, which are burned/converted to valuable functionality by way of one or more sprints.

I'm asking the reader to assume that we are setting appropriate goals, making proper use of controls, acceptance criteria, etc., and that we understand our reasons for using Scrum, etc., etc.

I imagine having this document has an impact on what is achieved. What is its effect?

Some things to consider (although it's not an exhaustive list):

Is quality affected? (for quality, perhaps consider something measurable, like an increase or decrease in the number of defects, or the ratio of defects relative to items of value being delivered)

Is the cycle time for development affected? (by cycle time I mean the time from when development begins on an item to when it is done. This is not time worked. It's essentially marking one day on a calendar at the start, and the day at the end, and counting the gap)

Is the lead time affected? (this is similar to cycle time, but instead count the start as some clear moment at the beginning of the process, like when the idea emerged, or was added to the backlog. Again count the end as when it is done, or even when it is used by customers, or the first feedback/learning is received)

Are more or fewer items able to be delivered in a given timeframe, with this approach?

Is more or less value being realized with this approach?

My question was solely about our use of the intermediate 'model' document, which is created based on user stories. Then based on the model, we identify tasks, which are burned/converted to valuable functionality by way of one or more sprints.

Is it clear to the team when they need this model, and why? Is it something they elicit during Product Backlog refinement, for example, and which they use to bring work to a "ready" state? Or is it something they elicit in Sprint Planning itself, and which is then executed as part of that plan?

Thanks for your thoughts so far. Honestly, we use this approach only when we can't think of any other. It's usually for the initial development of a product's core architectural components. Let me use a ridiculous non-software example to stretch my point.

Consider a few of the requirements for the design of a fictitious airliner: It must fly at Mach 2, it must be able to cruise at an altitude of 60,000 feet, it must accommodate 250 passengers, cabin noise level must not exceed 55dB. Each of these requirements affects very many aspects of the design, and you can't realistically assign timescale, cost or effort to any one of these requirements in isolation. You have to think systemically.

So, I suppose my real question is: when you're developing a software component that demands this kind of systemic consideration, is there any best practice or good practice that addresses this, other than the approach I outlined at the start? Are we missing something?

To answer Ian's question specifically, if we use a model as I described, it's something we currently elicit as part of backlog refinement.

It sounds as though the "model" is being used to make systemic predictions about a complex product, where more is unknown than is known.

The complex domain is indeed the sweet spot for Scrum. However, Scrum eschews a model-theoretic approach in favor of rapid experimentation. Rather than trying to elicit a predictive systemic "model", we ask ourselves "what is the smallest empirical experiment we can conduct, from which validated learning will emerge?"

In practice, our (so-called) model isn't a formal predictive model in the sense I think you mean; it's is usually no more than an abstraction of the required outcome, serving as a means to elicit quantifiable development tasks. But this model is the culmination of the creative process that reconciles expert knowledge with unstructured user needs - involving experimentation, imagination, left brain, right brain, etc. So yes, this process is, in itself, complex adaptive, and it can take days or weeks to complete. And timescale can be estimated with some confidence. Are we, therefore, moving towards the suggestion that the creation of our so-called model could legitimately sit within one or more sprints, and that the resulting model (sprint outcome) then informs the planning of further sprints? Or, am I still overlooking fundamental Scrum principles?

It could possibly be a refinement activity, undertaken each Sprint, which readies work for future Sprints. What matters is that it leaves the team enough room for creative experiment to make sprinting worthwhile.

...continued...

Just to expand on what I wrote just now - I acknowledged that the creation of the model is, in itself, complex adaptive, meaning that there will be some degree of iteration in there. But reducing that creation process into further 'iterations' in the Scrum sense of the word, although ostensibly logical, just seems to impose an overhead in practice, not least because it seems to disrupt the creative flow.

"What matters is that it leaves the team enough room for creative experiment to make sprinting worthwhile."

Yes, emphatically, that's very much the case. The so-called model is never more than an abstract, the minimum necessary for conceiving the system.