Story splitting: Tiny business requirement vs big code

What are the risks, and where are the uncertainties?
- Are the multiple processes and staging tables well defined?
- Is the work that will be needed clear to the Development Team?

From a business perspective it is as granular as can be.

Well, let's dive a little deeper, shall we? ;-)

1) The data "element" becomes visible to the users after the e-2-e approach is finished. How is the data presented to the users? Through a report? A screen? A file? Can the presentation format be identified as a standalone story, separate from any processing and staging tables, and confirmed with the business?

2) The data "element" is subjected to multiple processing and staging tables. Are there rules within these multiple steps that may affect the content of the data element? If so, then I am assuming that you have different acceptance criteria for the various possibilities, and you can certainly split your story along different acceptance criteria.

3) In considering your

What I would highly advise against are any of the ideas you presented.

Do not change the length of your sprint

Do not change the length of your sprint

From a business perspective it is as granular as can be.

Well, let's dive a little deeper, shall we? ;-)

1) The data "element" becomes visible to the users after the e-2-e (end-to-end) approach is finished. How is the data presented to the users? Through a report? A screen? A file? Can the presentation format be identified as a standalone story, separate from any processing and staging tables, and confirmed with the business?

2) The data "element" is subjected to multiple processing and staging tables. Are there rules within these multiple steps that may affect the content of the data element? If so, then I am assuming that you have different acceptance criteria for the various possibilities, and you can certainly split your story along different acceptance criteria.

3) You have an e-2-e process with multiple stages. Can you identify a single "happy path" through all of the stages that would move that data element through to the end? If so, that can be one story, and all of your variations to the path become additional stories built upon that single proven happy path.

This is just an initial stab at splitting your story. There certainly can be other options.

What I would highly advise against are any of the ideas you presented.

Do not change the length of your sprint

Do not create "task" stories that don't individually provide value to the business

Do not split the story along team specialization (i.e. - developer/tester stories)

Hope this helps. Good luck.

Ian - there are very few risks and uncertainties.
The process and staging tables are well defined.
The work is clear to the development team.

Hi Timothy,

1) The data is presented to the user in many ways (UI/report/API calls). However, a separate user story exists for each. Most already exist. The data gathered will be inserted into a pre-existing part of the data model, therefore no additional display work is required.

2) Absolutely - I can (and have) identified the various stages of the process. And I have detailed their acceptance criteria. However, these rules are 100% technical, and totally based on the chosen source system. If I chose to import the data from a different source, they would all be different. Note: The system users have no awareness of any of these source systems - they just know that they want the data!

3) Yes. There is a happy path. However, the user story I am describing was for that happy path. I am dealing with any "exception workflows" in separate user stories.

Like I said, I believe that I have chipped away anything which could form its own business-relevant user-story. What I'm left with is a large technical task which is only visible to the user when complete.

I appreciate your 3 "Do not"s. I knew when I was writing the that they were consider bad practice in scrum. However, they're the only paths I can see. What I need is a 4th path.

I have spent several days reading though articles about "Splitting User Stories". In every case they seem to avoid the possibility that there is such a thing as a technical task which does not split into business tasks. Every example is hand-picked to allow this business-relevant splitting.

What am I missing?

> Ian - there are very few risks and
> uncertainties. 
> The process and staging tables are well defined.
> The work is clear to the development team. 

Scrum is optimized for conditions of high uncertainty where complex products are to be developed. Sprints are a mechanism for controlling the associated risks.

It *sounds* as though you aren't facing a great deal of risk, either business or technical. If that's the case, then this may be one of the rare cases where a predictive stage-gated approach might reasonably be applied.

However, I'm still not convinced that the risks are as limited as you suggest. The user story you are struggling to break down represents a large batch of work. That suggests the work is not entirely simple to do, and that (at the very least) there will be accumulative risk exposure of some sort over the extended course of its development. Is there really so little that might go wrong?

Andrew,

While there are certainly situations where a purely technical effort is required that would be completely transparent to the end user (i.e. - system upgrades, re-platforming functionality, etc.), I do not believe that your scenario truly falls under this "umbrella".

I understand that you seem to have painted yourself into a corner around your "technical" story, but I view this as a symptom of poor grooming (horizontal slicing instead of vertical), and not reflective of the actual business situation.

For discussion purposes, let's just label this new data element as FIELD A.

- According to you, FIELD A can be displayed to the user through several methods (UI/report/API calls). You state that separate user stories currently exist to support providing FIELD A to each type of output. While that is good, you do not detail the story content. Is FIELD A derived from the same source for each of these output stories? Is the content of FIELD A the same for each of these outputs?

- Do your users know how FIELD A will be presented in each of your output methods (how it will look)? You can create separate "format" stories to show the users how the new data will be presented, without actually populating it.

- You state that the users don't care about the data source, they just want to see FIELD A. How is the business currently doing their job without being able to readily access FIELD A?

- If FIELD A does not change at all from source to display, then why does it need to go through multiple process and staging tables? Why can't you just derive what the users need from one source?

- If the contents of FIELD A does changes from source to display, then every permutation or possible massaging of data content becomes another story.

Regarding my three "dont's", they are simply needed if you want to approach this effort through Scrum. If you choose to violate any of these 3 "dont's", that is fine, but understand that you are no longer approaching this via Scrum.

I guess my final thought on this topic is this: Why is the design and development of the story being done in a silo (you) without participation or contribution from the business (users)? Very often, team members who are developers struggle with non-technical story identification and development.

It seems you are proceeding with what you know (technical solution), and noticing that it somehow doesn't conform to Scrum. Collaboration on the story with your customer, and working with an Agile Coach or someone outside the team experienced in story mapping and creation, may be in order.

Hi Ian,
based on your last comment it sounds like you're suggesting that I treat this one user story as an independent big-design-up-front project. Is that correct?

In general the overall project is full of risk and uncertainty. Scrum has served us very well in allowing us to finally get the project moving.

This one particular task however is well understood. We effectively have to pull data from one Oracle database to another (and perform a transformation process). We could perform the process manually if we wanted to. The complexity of the task lies in performance; making the correct decisions in terms of technology and choosing the correct architecture to enable concurrent querying/processing of the data. None of the challenges pose any risk to the business requirements.

Given that this is the case, would you recommend that we treat this as a separate project? If so, is it just a case of removing members from the "core" scrum team and reducing velocity until it's done?

Hi Timothy -
ha ha - you're right. It's hard to give a detailed description of a story while keeping the business use confidential. But let me see if I can shed any light on it by use of an analogy. How about an animal shelter? That's a good cause, right?

-- Animal meal planner requirements --

I'm writing a system to help the animal shelter know what food it needs to order in to feed its animals. Animals arrive in all the time. Dogs of all shapes and sizes, cats, even a flamingo once. Most of the volunteers have no idea what, and how much, each of these animals eat so they rely on a local vet to leave little notes each day beside their pens.

My system is designed to automate this process and send the meal requirements to the volunteer's phone when they scan a little 3D bar code on the pen door.

It's been working great. Right now the system allows the vet to assess each animal when it arrives in the shelter, scans it's chip (if it has one) and manually enters the meals the animals will need. The volunteers are very happy, but it's still a lot of work for the vet.

The shelter has recently subscribed to an "animal foods" database. Based on the type of animal (on information contained in its chip) the system can tell you its meal requirements.

Our new user story is:

As the vet
I want the animals' meal requirements to be automatically populated when I scan their chip (where available)
So that I don't have to manually look up and enter the meal plan

Right now, our system has the following events:
"Chip scanned" - when the animal's chip is scanned (containing data about the animal)
"Meal plan created" - when the vet creates a meal plan

Both events currently trigger various other units of functionality (both graphical and non-graphical).

We intend to create a component which receives the "Chip scanned" event and attempts to import the meal plan from the animal foods database. If successful it throws a "Meal plan created" event. If not, the poor vet just continues as he did before.

---------------------------------

Notes:
i) This is probably a terrible analogy. In two responses time it's bound to fall apart!
ii) This sounds like a brilliant system. If there are any animal shelters out there who agree, I'm available for a very reasonable rate. :-P


-- Back to Tim's points .... --

Is FIELD A derived from the same source for each of these output stories?

No. There are multiple mechanisms for entering a meal plan (sticking with the analogy here). The vet manually entering it and importing it from the animal foods DB are only two,

Is the content of FIELD A the same for each of these outputs?

Yes.

Do your users know how FIELD A will be presented in each of your output methods (how it will look)? You can create separate "format" stories to show the users how the new data will be presented, without actually populating it.

Not required, The output is already defined and handled.

You state that the users don't care about the data source, they just want to see FIELD A. How is the business currently doing their job without being able to readily access FIELD A?

The vet is very busy!

If FIELD A does not change at all from source to display, then why does it need to go through multiple process and staging tables? Why can't you just derive what the users need from one source?

The animal food database was not written with oursystem in mind (and vice versa). Constructing a meal plan for our system takes some processing.

If the contents of FIELD A does changes from source to display, then every permutation or possible massaging of data content becomes another story.

Agreed. This is our current situation. If we were expected to create yet another method for entering a meal plan, we would expect to write another user story for it.


In general (as I said to Ian) I'm very very happy with scrum. It's worked very well for us so far. That's why I'd like to better understand what I'm doing wrong in this case. I'd very much like to use it going forward, so overcoming hurdles like this now are important to me.

Can you see any way I can approach this problem while sticking to scrum?

Apologies Andrew. You lost me with your animal shelter analogy. Unsure why you didn't continue the discussion around importing a single data element, like you presented in your original post.

All that I can do is provide you with advice and direction based on my observations and experience. It is up to you whether you are receptive to it or not.

If you want to stick with Scrum to solve this business problem, I would provide this closing advice:

- Stop trying to design the story on your own. Collaborate with your user(s), and create multiple stories that individually provide some level of function or benefit to the business.

- Work with someone knowledgeable in Scrum and story mapping to help you and your users identify stories from a vertical perspective, and not from a horizontal slice of functionality. Horizontal slicing creates "technical" or task-based stories.

Good luck to you in your future endeavors.

Thanks Tim - sorry if anything I've said seems unperceptive, nothing could be further from the truth.

I didn't actually write the original story; it came in from the business pretty much in it's existing form. If our sprints were two or three times longer it would be a perfect story.

It's us developers that are butchering it trying to fit it into our sprint cycles. The rest of the team have come to the conclusion that "Scrum doesn't work". I'm trying to prove them wrong.

> This one particular task however is well understood.
...
> The complexity of the task lies in performance;
> making the correct decisions in terms of technology
> and choosing the correct architecture
...
> Given that this is the case, would you recommend
> that we treat this as a separate project?

No, because there are still risks to be managed. You should continue sprinting in order to control them.

It appears that this work is different not because of the absence of risk, but because the nature of the risks has changed. They are no longer so much business risks, and are rather more about technology and architecture.

It seems that this is the root of your current problem. User Stories are a good way of capturing business requirements and the associated risks. They aren't so hot when it comes to controlling technological and architectural uncertainties.

Now, remember that the Scrum framework does not mandate User Stories. A backlog may be populated with anything suitable, as long as it can be ordered and described, and given an estimate and a value.

My suggestion is therefore to avoid a User Story in this case. Express the requirement in terms of the risks that are in fact present. Even if they are technological or architectural, they will still have a potential impact on delivery. A good Product Owner will care about that and will be interested in seeing those risks incrementally mitigated.

NB bear in mind that a Scrum increment should deliver some additional functionality, no matter how small. The Development Team could therefore spend the bulk of the sprint mitigating technogical or architectural risk while also delivering at least one other user story. It would be best if this story helped to validate the data transformation in some way, but that does not have to be the case. Even the most trivial feature-complete addition is better than providing none.

Thanks Ian, that's almost the approach I went for. Time ran out and I was forced to make a decision.

In the end I created 3 "Developer stories" to represent the user story, but kept the original user story in the backlog. In terms of velocity/estimates we're treating the developer stories as user stories. We've set the "effort" of the original user story to zero, but will move it through when the developer tasks are complete.

There's a lot wrong with this solution: Duplicate stories. "Developer stories" are a horrible mechanism. Etc.

If anyone can suggest a better one or direct me toward any books or articles on the subject, I'd be grateful.

Thanks to everyone for their time.