I am writing a template story document and want to include as many elements as will make for useful, generic stories. Currently, this includes:

  • Story number
  • Points estimate (fibonacci)
  • State (to do, in dev, done, etc)
  • Priority
  • Blocked flag
  • Author
  • Assignee
  • Title
  • Short description
  • Description
  • Tech notes (bullet point items purely for reference)
  • Acceptance criteria (bullet point items to be ticked off before testing)
  • Scenarios (Given When Then for each unique use case)
  • User journeys (Optional variations as numbered steps which an be applied to the scenarios to provide variations on tests)

My question is: Should I be avoiding User Journeys altogether or do they still have a place in this sort of story?

Also, am I missing anything which might jump out at you as a developer or story author?


It depends on the story and the team. So during sprint planning, you would discuss the high value stories with the development team, who in return ask for clarity. You should ask them whether adding a user journey going to be helpful.

A side note here: do you think you can add such detail for each and every story as long as the project goes on? More importantly, is there a reason you are having to document all that instead of just interacting with rest of the team?

My preference on backlog refinement: As far as product backlog management goes, I always like to write as little as possible and decompose the stories as late as possible, but before the sprint planning. Then, during sprint planning, you decompose further and add sub-tasks to each story along with the dev-team to make up the sprint backlog. Obviously you cannot do that for all stories so respect the time-box, and do the rest as the sprint progresses. This minimizes waste and allows the team to focus on value.

| improve this answer | |
  • 1
    Thank you. This would be my experience previously, as well. I'd like to know if you would try to avoid user journeys alongside scenarios and, if not, how they can work together. I'm currently considering having the scenarios and using user journeys to provide varying data for the scenarios to be implemented as test suites with multiple inputs. – Matt W Aug 3 '17 at 10:15
  • A persona may have one or more journey, with each journey having one or more scenario. A journey generally does even include things that happen outside of the product. So I wouldn't avoid using them together. – Muhammad Aug 3 '17 at 10:35

Remember that Agile manifesto emphasizes value of

Individuals and interactions over processes and tools

It looks like you are trying to turn user stories into a central holder-of-everything piece of the process. They are future conversations placeholders and that's it.

For example you are introducing "Title", "Short description", "Description" and "Scenarios". Why do you need all of this in a user story?

Should I be avoiding User Journeys altogether or do they still have a place in this sort of story?

You should not avoid user journeys of course, they are part of reality. But do you really need to place them (and scenarios) into user story? Aren't they already covered by your tests since you are doing BDD? Aren't they in your documentation afterwards?

Scenarios (Given When Then for each unique use case)

"Given When Then" is a format of acceptance tests, better call this way to avoid confusion with use cases. Apart from that if you are writing "Given When Then" for use cases - they should be connected to use cases, not stories.

| improve this answer | |

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.