In Scrum, how to handle a functionality that could be used by more than one feature?

Question

Is there a principle in Scrum for packaging the different views of the project into different owners' perspectives, or do I just need to get more practice in picking the pieces I need out of the stories?

From a developer's perspective, I see a number of times where we either break a logical set of development work across multiple stories or lump multiple sets of work into one story. This has led to difficulty in assuring the requirements are met and discussing relationships between components with other developers.

My group uses Atlassian's Jira. At least our implementation seems to be more of a strictly hierarchical layout vs. facet-based. So an epic has stories, stories have sub-tasks, etc. But there's no way to collect parts spread across multiple stories into a unit of development work, such as making one sub-task that is the child of three stories.

Example 1 - Splitting one unit A proxy service routes a specific client's orders. It receives, validates and passes on the client's request. A standard intake then handles the request. A change to accept four new values has been split into two separate stories--one for discussing failing validation and one for happy path.

While a user may see two different outcomes, a developer it is handling the contingencies of one new set of input.

Example 2 - One concept, multiple components 10 new events will be reported in two different business categories. Events 1-5 are in Story A. 6-10 are in Story B. Architecturally, Component 1 will receive all 10 events and configuration will handle the detail of each variation. Then Component 2 will consume Component 1's results, again with one mechanism change.

This combines both components into a single story, then does so again. From a developer perspective, the delineation of work is between components, not event categories.

Answer 1

Use Spykes.

A Spyke is a technical investigation to produce an answer in regards to some acceptance criteria on a PBI prioritized in upcoming Sprints. Consider this as a kind of enabler to break down the implementation complexity, such as how the minimal functionality could be developed in order to deliver upcoming stories.

Definitely easier said than done.

With that in mind, depending on how messy "monolithic" your code is, the harder it'll be to make the best use of spykes. As the article mention, they should be the exception, not the rule for such implementations.

Besides, agile says "working software over comprehensive documentation", not "working software and no documentation". Depending on how complex your application is, you may need to dedicate more or less time to document (or socialise) your project changes.

Answer 2

There are actually two parts of an answer to this. The technical coding part and the backlog refinement part.

Backlog Refinement

In the backlog refinement meeting, there should be a conversation between the Product Owner and the team where things like this come to light. There may be some cases where working features in a specific way or order actually makes them far more difficult and, therefor, expensive. In some cases, the value created with this order is great enough that it is worth the cost. In other cases, the order or grouping is just coincidence, and the Product Owner will happily adjust the backlog for a less expensive, easier way of building out the product.

Technical - Decoupled Code

This problem becomes less and less frequent the more module your code is. In an ideal situation, if I have features A, B, and C and they all contribute to some architectural component, like a messaging layer, I'd like to be able to do any of these first and only build the part of that messaging layer that I need for that feature. Then the part I need for the next feature, and so on. Also ideally, this should not result in significant rework. Respecting principles like dependency inversion, open-closed principle, and single-responsibility goes a long way toward having loosely coupled or decoupled code.

Now, this is easier to do in some things than others. With practice, you'll find more and more ways to do it. Sometimes there is a question of "should I code this way" since doing it all at once is more efficient. The answer most of the time is this: if you don't change it now, you will in the future. Very little code that is ever written in only touched once in the life of the application.