As a Product Owner, I am working with a team that use the 'AS A / I WANT / SO THAT' style of user story. I have a system that has a several workflows to be followed depending on the setting of certain fields (they determine the sequence of downstream activities and whether some are skipped etc). It looks like I have two options:

Write one story something like AS AN administrator I WANT to set parameters SO THAT downstream activities follow the correct path. I would need to attach a flowchart to the story.

OR write one story for each configuration of parameters and then what I want to happen downstream for each.

The second approach seems to be following Mike Cohns advice to break down in to smaller stories, but then the 'I WANT' bit has to get really detailed and possibly quite sequential 'I WANT this and this and if this then this etc'

Which approach is more effective?

  • Hi, I'm not sure if these stories are backend or frontend oriented. I'd guess they're backend but would be good if you could confirm that.
    – Tiago Cardoso
    Commented Feb 28, 2019 at 23:00
  • 1
    Stories are not specifications. They are conversation starters.
    – Todd A. Jacobs
    Commented Mar 1, 2019 at 2:23
  • @TiagoCardoso - backend stories, I think. They are around the workflow path to be followed based on the initial captured parameters. To add a little more detail this is a document signature process - sometimes it requires 2 parties to sign, sometimes 1 and the order of signing can vary. Depending on the parameters captured the automation has to drive the sequence accordingly.
    – sgb1960
    Commented Mar 1, 2019 at 11:00
  • @ToddA.Jacobs - in our organisation's adoption of agile, it would seem that stories are specifications. They are what we test against, carry out UAT on and finally declare as DONE. I think if they were only conversation starters then UAT and DONE etc would need to be done against some other artefact. Having said that, I agree with you that actually they should be that. But if that is the case, then where do you recommend holding the detail that gets generated from the conversations you have started?
    – sgb1960
    Commented Mar 1, 2019 at 11:03

3 Answers 3



Neither of your current user stories will work. This isn't simply a result of writing the stories incorrectly; it's a direct result of a non-agile approach to large systems development.

Below, I describe what user stories are and aren't. I also discuss other tools that may complement your user stories, especially in regards to providing additional scope and context. And finally, I provide some recommendations for making your systems development process more flexible through emergent design, and better able to embrace complexity through iterative development.

User Stories are Not Specifications or Requirements

User stories are many things:

  • Conversation starters.
  • A starting point for customer collaboration.
  • Deliberately high-level feature descriptions or acceptance criteria.
  • Brief (even shorthand) use cases that describe a value proposition and a value consumer.

One thing they are not, however, is a technical specification or detailed requirement document. No less an expert on user stories than Mike Cohn has explicitly stated that user stories are not specifications.

While a product backlog can be thought of as a replacement for the requirements document of a traditional project, it is important to remember that the written part of an agile user story (“As a user, I want …”) is incomplete until the discussions about that story occur.

It’s often best to think of the written part as a pointer to the real requirement. User stories could point to a diagram depicting a workflow, a spreadsheet showing how to perform a calculation, or any other artifact the product owner or team desires.

Use More Appropriate Tools

Depending on what you're trying to express, other tools and artifacts are often more effective than user stories in defining specific elements for your product. Many of them can be used in conjunction with user stories.

A Product Backlog holds features to be developed, but leave the implementation details to collaboration between the development team and users. Workflows are generally captured with user story mapping or user journeys. Acceptance criteria are often best expressed through Cucumber features. You might even have other project artifacts that hold additional detail about functional and non-functional requirements.

"Agile" doesn't require you to try to stuff all of the details of your product into user stories. Stories are just one tool (among many) for meeting the values and principles of agility.

Analyzing Your Use Case

Write one story something like AS AN administrator I WANT to set parameters SO THAT downstream activities follow the correct path. I would need to attach a flowchart to the story.

This is only partially correct. The administrator is not the value consumer, so you want to identify the user who will take the UX journey, use the feature, or gain the benefit. That way, the team can collaborate with them or their chosen proxy. In addition, such a story is not inherently testable. While attaching (or referring to) a flow chart is certainly a useful thing to do, such a vague story won't provide sufficient context to develop a test-first solution.

Your other alternative is worse:

write one story for each configuration of parameters and then what I want to happen downstream for each.

This attempts to shoehorn detailed specifications into each story. While possibly testable, this type of approach overly constrains the solution space to the point where you lose most of the benefits of an agile approach.

You are essentially taking a whole-systems, "big upfront planning" approach to your design and implementation. This is inherently non-agile, and the unwieldiness of this approach is contributing to the awkward stories you're finding on the backlog.

Choosing between too-big epics and overly-details specification documents is a false dichotomy. Neither is the right choice. A more agile, just-in-time design approach along with iterative development will resolve most of the problems you're currently describing.


First, accept that agile frameworks are both incremental and iterative. You don't have to design and implement the whole system all at once. Instead, you build up the system piece by piece. This often results in refactoring and rework as the team collaborates with the customer on what's actually needed, rather than simply on what's been asked for in the beginning. This is a fundamental mind-shift that must take place for a project to be agile, and for it to succeed.

Second, foster collaboration. A user story should describe a vertical slice of functionality that serves as a conversation starter between the development team and the users. For example, a good user story might be:

As an HR administrator,
I want the system to automatically reject all resumes
so that I don't have to print them out and circular-file each one manually.

This story describes a value consumer that the team can collaborate with to validate acceptance criteria and feature fit (the HR admin). It also describes a feature without overly constraining the solution space; it says what is wanted, rather than how it will be implemented by the system. And finally, it provides context that helps the development team craft a solution that not only meets the goal, but that can also guide implementation choices to better fit into the user's workflow.

Iterating and Refactoring

In a big system, there will be many of these types of stories. Each iteration should deliver an increment of potentially-shippable functionality. However, when the system is extremely large or complex, later stories may require changes or modifications to the system to accommodate the new features without breaking the old ones. This is an expected aspect of agile projects.

This "emergent design" is handled by refactoring (changing implementation details without impacting behavior), or by accepting that there will be additional work involved in updating aspects of the system. As an example, let's suppose that some future bit of work says:

As a compliance officer
I want all incoming documents to be saved for 7 years
so that regulators can never find their needles in our haystacks.

Maybe the HR admin's story was implemented with a "reject and delete" approach, because the team didn't yet have this new context in scope. So, the team may need to refactor the HR functionality to reject-and-store as part of this new compliance story, and that level-of-effort would be factored into the new story's estimate during iteration planning. Or perhaps the new story can't be implemented without changing something more fundamental about the system. In that case, the fundamental changes are analyzed, decomposed, and put on the Product Backlog just like any other work for the project.

Agile frameworks embrace change. Incremental/iterative development, refactoring, and rework are inherent to the agile approach. By providing transparency within the Product Backlog, you may reduce unnecessary rework by consolidating related items together so that any conflicting context or workflow differences can be spotted more easily, but you'll never eliminate rework entirely. Accept the benefits of agility (such as the ability to deliver small, complete slices of functionality quickly), and treat refactoring and rework as a basic cost of doing business this way.

  • 2
    Todd - you have really gone the extra mile with your response here. Many thanks. I am thinking of running a workshop on story writing with several teams from our Agile Release Train and you have provided a huge amount here to discuss and debate. Many thanks!
    – sgb1960
    Commented Mar 3, 2019 at 20:49

The purpose of the As A X I want Y so that Z is to create an understanding of the user's needs. I feel like in your situation, it may be ill-suited to effectively describing what is needed.

That said, it might be worth reaching out to local coaches or even the local agile community to have someone help you through some backlog refinement with user stories and they may be a great way to do it with your situation. But if you look at a situation and say "I have no idea how to fit this in that format" and you just jam it in, you are almost certainly doing yourself and the team a disservice.

Edit: To be clear, I'm not saying you can't. You absolutely can. I'm just suggesting that if your business workflow is incredibly complex, the solution for your specific situation will probably be very difficult if not impossible to answer here.


Would it be an option to check with the team? If you explain the situation to them and what you want to achieve, they might be able to tell what they think is usable. I have had the same situation where one story described multiple actions and the team indicated that it would be better to split them in separate stories. In other occasions they indicated to group actions because they are linked together so closely that it would be more efficient to work on them together.

  • I did in fact do this and we concluded that we would take it piecemeal. We have mocked up the parameter capturing piece, so that we can demonstrate that to our users. Once we have got that mechanism accepted an agreed, we will then work on the scenarios as separate stories. Thanks for taking the time.
    – sgb1960
    Commented Mar 1, 2019 at 11:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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