3

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.

  • 1
    I suspect the problem is that you're using "user stories" to track tasks or implementation details, rather than actual stories. A great user story has a consumer (POV), a feature request, and a scope. Implementation details, specifications, and tasks should generally not be part of a user story. – Todd A. Jacobs Feb 7 at 20:07
  • I think you might be onto something in terms of scoping stories. Especially in Example 1. The two stories, to me, are really one. A user provides input and has a set of results from it. I'm still stuck on example 2 where the scope of each story makes some sense (two different user roles lead to two different sets of events) but all of the mechanics are one unit of development. Would it make sense to have two stories, make completion of one dependent upon the other then place all dev sub-tasks under the first? – John Spiegel Feb 8 at 15:43
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.

  • thanks. The difficulty is less in determining what to be done and more in how to compile the results of that research. The user-centric view of what we're going to accomplish is often very different from how the architecture goes about it. This leaves a fairly simple unit of work documented in many different areas. – John Spiegel Feb 7 at 17:20
0

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.

  • Thanks, Daniel. My challenge lies, I think, in how to record/depict the results of backlog refinement. What users think of as three separate outcomes are reasonably part of one architectural point. I envision something like a set of underlying sub-tasks. And then two different containers, user stories and dev stories, that each group those individual sub-tasks into the particular audience's needs??? – John Spiegel Feb 7 at 16:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.