Are my user stories too long?

As a Product Owner its tempting to try and capture as much detail as possible on a user story. I might start with a simple requirement, but then end up adding loads of additional information!

Of course, we all know that a user story, at its essence is just meant to be a statement in the following format:

As a [persona] I want [a feature] so that [business value]

  • The persona is the person (or sometime system) that wants to do something
  • The feature is the thing they want to do
  • The business value is the reason why they want to do it

Or in other words, we capture the who, what, and why of a requirement.

But then we’re told that we should add more information to the story – such as the acceptance criteria, any assumptions we’re making, and maybe even statements about scope and dependencies.

A lot of Product Owners also write their acceptance criteria as gherkin scenarios for use with automated testing.

In the past I’ve ended up with JIRA tickets that go on for pages and pages. There have been a few paragraphs of background information, a dozen or more gherkin scenarios covering every eventuality together with UI wireframes, and links to supporting information.

Some may say that my stories are too big – not just in story points – but in length. But if I’ve done a lot of research and analysis shouldn’t I capture it all in the JIRA ticket so that there’s a written record?

The Three C’s

Ron Jeffreys suggests that we adopt the Three C’s approach to User Stories: Card, Collaboration, and Confirmation:

  • Card – the user story should be written on a physical index card – one that can be stuck up on the wall. With the limited space of the card, it forces the writer to be succinct.
  • Collaboration – a discussion between the Product Owner and developers about the story, including an exchange of thoughts and opinions about the requirements.
  • Confirmation – clarifying what’s required in order to deliver the story, with the capture acceptance criteria. The suggestion is that these are written on the back of the index card.

This use of the physical card does encourage brevity of writing and instead relies upon communication of the requirement through conversation.

However this relies on a team that is comfortable with constantly communicating and asking questions – and in my experience some developers are reluctant to say when they don’t understand something or they are not sure. Some will even sit for 3 days pondering a multitude of options instead of having a 5-minute chat to clarify an issue.

Waterfall stories

And so, with a team who aren’t naturally inclined to ask questions, and a JIRA system with an unlimited amount of space for me to record information, it’s no wonder I might be tempted to write long stories!

At least it means that the team can check the JIRA ticket if they’re not sure about anything.

I am aware, however, that it does mean that I’m moving a bit away from Agile and back towards the Waterfall days of 200-page requirements specifications!

It’s back to the practise of spending days crafting reams of documentation – which, having made all the effort to write it, probably makes me a bit reluctant to change!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Because of a 2011 EU directive designed to protect your online privacy, I am required by law to check you are OK with the use of cookies on this site. Click here for more information.

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close