27

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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Joe Young
  • 381
  • 3
  • 4
  • 4
    if you're going to use ["technical user stories"](http://rgalen.com/agile-training-news/2013/11/10/technical-user-stories-what-when-and-how) realize that there are 3 things here not 4. The differences you calculate from your model and two kinds of views, a PDF view and a GUI view. You're just presenting the report differently. – candied_orange Dec 20 '17 at 17:41
  • 1
    Tackle one of them. Then tackle the other. It is that simple. – Ant P Dec 22 '17 at 00:59
  • Why are they two stories? – JeffO Jan 09 '18 at 22:52

5 Answers5

55

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.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • 3
    Was actually beginning to write something very similar, but this answer covers already all aspects of mine, so +1. – Doc Brown Dec 20 '17 at 17:32
  • Same here, keep implementation out of it. – candied_orange Dec 20 '17 at 17:39
  • Ok, so I can understand that. But where then do the technical / implementation details go? If I am writing this for another developer to work on, how do I relay that information to them? Probably better suited as another question. – Joe Young Dec 20 '17 at 17:48
  • 1
    @JoeYoung: implementation details go - into the implementation, where else? And how you tell this another developer depends on the communication structure of your team. Of course, there might a functional requirement involved here, like *"when viewing payroll differences online, or when retrieving them as PDF, it is important to get exactly the same content in both cases"*. If that is the case, add this as a note to at least one (better both) user stories. However, don't put any description how this requirement will be implemented into the story. – Doc Brown Dec 20 '17 at 18:07
  • 3
    Design isn't about telling a developer how to solve problems. It's telling a developer what problems to solve. – candied_orange Dec 20 '17 at 22:12
  • User stories simply bridge the gap between the business and the developer using language they can both understand – jpotts18 Dec 21 '17 at 04:43
  • 1
    When you rate the time cost of these stories, how do you then rate them? Let's say the common query part takes 5 hours, the web-view part takes 6 hours, and the PDF-view part takes 7 hours. Do you estimate the time, do you arbitrarily say one costs 11 hours (5+6) and the other 7 (or vice-versa: 12 and 6), or do you estimate them at 6 and 7, but note somewhere else in some way the 5 hour overhead for both of them combined? 11 and 12 (the 5 added to both)? If you say "This model isn't intended to handle such cases. Just talk it out." it might still be recorded on a storyboard, but how? – Aaron Dec 21 '17 at 17:56
15

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.

Ewan
  • 70,664
  • 5
  • 76
  • 161
4

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
Berin Loritsch
  • 45,784
  • 7
  • 87
  • 160
  • It is worth noting that you don't necessarily *need* to document any more than the story. The story gives you the business-level context. What more granular tracking you need is up to you (and largely dependent on organisational constraints). You should aim to minimise it though (people over process and all that). – Ant P Dec 22 '17 at 01:01
  • @AntP, agreed, but this goes toward the Definition of Done (DoD) and it _should_ fit on the back of your 3x5 card that has the user story. – Berin Loritsch Dec 22 '17 at 12:50
2

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.

Ilessa
  • 129
  • 4
2

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.

CodeGnome
  • 1,270
  • 7
  • 13