4

I often come across situations where creating and editing actions are very similar, but they are not exactly the same story. So should they be handled as separate user stories, or as one? For example, I could have:

Option A:

US A1: As a system administrator, I want to create new user accounts so that I can specify what services the users can access, and the users can access the system.

US A2: As a system administrator, I want to manage user accounts so that I can change what services the users can access and reset their passwords.

vs

Option B:

US B1: As a system administrator, I want to create and manage user accounts so that I can specify what services the users can access, and ensure that the users can make use of the system.

Is approach A or B correct, or is it simply a matter of personal preference or pragmatism depending on the complexity of the create vs edit functionality?

5

The key thing to consider here is whether your stories are manageable chunks of work.

To be manageable they need to be:

  • Unambiguously defined
  • Fairly easy to estimate
  • Completable within a sprint

So, if you find that merging two stories somehow compromises any of the above points, then don't do it.

Personally, I prefer working with many small stories as I find it easier to estimate that way. The trade-off is that you then need to be careful about the ordering of related or dependent stories in your sprint (a fairly trivial task).

3

I think that Option A, with separate user stories, would be preferred.

User stories are requirements. There are a set of characteristics of a good requirement that tend to be well accepted. Option A ensures that your user stories are cohesive (addresses one and only one thing), atomic (does not contain conjunctions), and more easily verifiable than Option B.

From an estimation standpoint, it's probably easier to estimate each one individually by walking through the workflows and use cases. You'll probably see commonalities and/or dependencies between them (for example, you need to create one before you can edit one), but you can give more realistic estimates if you break them up into smaller pieces.

From an implementation standpoint, though, you would likely need to deliver both pieces of functionality together to make a release actually useful to an end user. That can be managed in the iteration planning, though. Depending on your release cycle, they may end up in one release but in different iterations, if a release doesn't happen after every iteration. It's all up to planning and management.

2

TL;DR They ought to be two separate, but related requirements.

The risk in running them as separate requirements is that you'll have duplicated code for the associated UI and underlying services. But the risk in combining them as a single requirement is that the edit path has a slightly different setup to it.


A create path would look something like this:

  • Authorized user (AU) logs in to the system, opens create user panel
  • AU enters in and verifies details for new user
  • AU submits create request to system
  • System validates that business rules regarding user accounts are met
  • Systems stores user account (likely an insert statement)

An edit path would look something like this:

  • Authorized user (AU) logs in to the system, opens edit user panel
  • AU requests user details to be retrieved
  • System retrieves user details and presents information to AU
  • AU adjusts details for new user
  • AU submits edit request to system
  • System validates that business rules regarding user accounts are met
  • Systems stores user account (likely an update statement)

There's some obvious re-use with the create and edit user panels. Likewise, the same routine to check business rules against the user account could be re-used.

But the create path does not need to retrieve existing user details, and it's possible that the create path will have slightly different prompts such as with password setup.

The final decision of which path to follow depends upon how your development team works. From my experience, having two separate user stories does a better job at representing the workload involved to project management. And generally the two tasks would be assigned to the same person which would reduce the need for additional communication / coordination while working on the requirements.


Looking at the broader perspective when you have closely related user stories, you need to take a moment and briefly sketch out what's involved for each story. If there is a significant difference between the stories, then I think you're better off using separate stories. This helps make sure the significant difference isn't buried within the combined story.

  • I think you may be focusing too much on the specific example given. I think the asker was more wondering about potential pitfalls of combining similar stories in general. – MetaFight Aug 25 '15 at 14:48
  • TL;DR followed by an answer twice as long as the question. – Matthew James Briggs Aug 30 '15 at 5:59
0

I think it really depends on the stories themselves, are you going to differentiate the process or administration of the two tasks?

I could envision a scenario where there really is no difference beyond whether or not you are creating a new record. This could be done as a single story.

I could also envision a scenario when only certain admins can create an account, but a larger group of application or service admins might be able to update their portions of the user account. This sounds like two(or more) user stories.

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.