How to deal with stories that share functionality

Question

I have two stories (I know they are missing the benefit part)

1. As a Credit Management User, I can view the current and previous payroll differences for Offices.
2. As a Credit Management User, I can receive an email containing a PDF of the current and previous payroll differences for Offices.

The two are related in that they would have the same Query / Filter criteria. The only difference is that in the "View" story, the results are displayed to the User and in "Email" story, the results are written to a PDF that is emailed to the User.

I am struggling with the separation of the common aspects of these two stories or if I should even do so.

For example, they will both have the same query, what they do with the results is different.

Should I separate the query out into another story that is purely technical?

The creation of the PDF and sending of the email should be done offline, should that become a technical story?

I could see breaking those two stories down into 2 functional stories and 2 technical stories.

1. As the System, I can calculate the differences in the current and previous payroll for Offices.

2. As a Credit Management User, I can view the differences in the current and previous payroll for Offices.

3. As the System, I can create a PDF document of the differences in the current and previous payroll for Offices.

4. As a Credit Management User, I can request to receive an email containing a PDF of the differences in the current and previous payroll for Offices.

The problem I keep coming back to is that the 4 stories are not independent and do not "slice the cake".

So I am not quite sure how to deal with these two.

Answer 1

User Stories are not system specifications or functional requirements. Rather, they are the beginning of a conversation that can lead to such specifications or requirements.

Accordingly, I would expect there to be overlap in the system implementation. User Stories are not meant to describe such functional overlap or to eliminate it. The purpose of User Stories is to capture functional expectations from a user's point of view, not to describe implementation details.

Answer 2

Don't: Try and split the stories, Do one story and then the other.

Do: Ensure the dev team is aware of the second story.

The problem with trying to plan out the detailed tasks and thing up a generic model that can handle both in an elegant way is that it's hard.

The purpose of user stories is to get stuff done. Elegant is a secondary objective and should be left to refactoring.

Obviously its super annoying if you take this to the max and don't tell anyone about the ten other similar tasks that need doing, but also its totally conceivable that the second or third task isn't thought of until the first is done. If you want to plan it all out go with waterfall.

Answer 3

In violent agreement with Robert Harvey, the purpose of a user story is to understand what the user needs to be able to do. As you do your grooming, the customer understands and cares about the user story, but the developers care about a bit more. Once you ask enough questions to understand and estimate the work, you can create tasks to support them.

In this particular case, you could create tasks that enable the core of both user stories that would be done along with whichever you tackle first.

The important things to add to the user story are:

• Acceptance Criteria
• Assumptions

Answer 4

Strictly speaking, User Stories are the promise of a conversation to understand the required outcome.

For example, taking your second user story

As a Credit Management User, I can receive an email containing a PDF of the current and previous payroll differences for Offices.

Think about the following:

• What is the user "need" which is driving this requirement? (Has the PDF in an email as a solution come from them? This might not address the need and your team could come up with a better solution)
• What is the minimum slice which can address this user "need" and validate your solution? Short feedback loops are valuable.

When approaching story splitting, remember your INVEST criteria where possible.

1. Independent
2. Negotiable
3. Valuable
4. Estimatable
5. Small
6. Testable

It is okay to have stories which have a natural ordering. Take that into consideration - usually the first story is larger as it brings in the functionality required and the second story builds on it.

I would challenge "technical" stories, as generally they are most likely to be tasks to help support the implementation of the user outcome focused stories.

Answer 5

TL;DR

Assuming both user stories are pulled into scope within the same iteration, it is the team's job to decompose the stories into an implementation plan and its attendant tasks. User stories provide context and scope; they aren't implementations, specifications, or punch list items.

Stories Should be Decomposed to Iteration Tasks

Whether you're following Scrum or some other agile methodology, it's a common error to skip the planning phase of an iteration. In Scrum, when a Product Backlog Item (it need not be a user story, strictly speaking) is pulled into the current Sprint, the team is then supposed to use part of Sprint Planning to factor out commonalities between work items, identify dependencies, and then develop a Sprint Backlog to capture the task-level work.

As you pointed out in your post, it's not uncommon (and is in fact desirable) for an agile iteration to contain closely related user stories. In Scrum, this is surfaced through the use of the Sprint Goal. Outside of the Scrum framework, it often still makes sense to pull in related stories because of their shared objectives or shared dependencies. By extracting and then working on the shared dependencies within a single iteration, teams can often avoid the need to refactor or iterate over code for similar-but-not-identical features in the future.

Tasks Implement Stories

Here's another way to think about dependency planning for user stories. In general:

1. An epic/theme is used for longer-term planning or grouping on a backlog.
2. A user story is used for communicating objectives, context, and scope.
3. Just-in-time planning is used to develop an implementation that fits within a single iteration.
4. Tasks implement the just-in-time plan that meets the Definition of Done for one or more user stories.

Treating user stories as an implementation plan or a task list is considered by most practitioners to be an agile anti-pattern. Whatever you choose to call it, don't skip the just-in-time planning phase of your agile framework, and make sure to track dependencies and shared implementation details somewhere within your team's process.