Skip to main content

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

Last post 07:57 am October 28, 2020 by john Green
10 replies
04:04 pm October 21, 2020

Scrum/Agile is quite a recent introduction within our organization. The following is an attempt to validate a behaviour that has quickly evolved in my development team. Would anyone care to comment on this behavior – in particular, have we already lost our way to some extent, in scrum terms?

In a simple, typical scenario, a user story starts life as a perceived requirement from an actor’s/user’s perspective. The story is validated, refined, prioritized, etc., and it translates into a unit of software development work, which is assigned to a sprint…

Simple Fulfilment of Stories

Sometimes, it doesn’t make sense for us to try to map stories to specific units of development work, on a one-to-one basis. For example, I need to fulfil several user stories which, collectively, describe the required behavior of a core architectural component such as a software engine component. But the component needs to be created holistically; there is no discernible mapping between user story and unit of work.

So, we take this approach: from those several user stories, we create a ‘model’ – in practice, this is a live, collaborative document in which we build up a holistic description of the desired behavior (e.g., a process diagram). Only then do we define work breakdown ‘tasks’ which feed the sprint. The original stories remain active until verification is complete…

Story Fulfilment via Model

Have we lost our way?

 


07:56 pm October 21, 2020

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?


05:22 am October 22, 2020

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.


05:20 pm October 22, 2020

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?


05:37 pm October 22, 2020

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?


07:00 am October 26, 2020

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.


01:05 pm October 26, 2020

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?"


09:41 pm October 26, 2020

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?


05:42 am October 27, 2020

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.


05:56 am October 27, 2020

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


07:57 am October 28, 2020

"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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.