The battle for the best user story description is far from the end. When teams are getting frustrated with agile, the first thing they usually point out as the problem is the user story. User stories tend to be the scapegoat.
This creates huge pressure on top of Product Owners, which are responsible for creating, maintaining long backlogs and writing requirements. A user story is the most important artifact requirement in an Agile project.
So, how should a Product Owner write a user story?
There are some discussions when someone tries to find an exact definition of: “How to write a good user story”. However there are good practices that we must keep in mind.
Dan North and Chris Matts, part of Creating Behaviour Driven acceptance criteria using the “given, when, then” format, provide us with a repeatable formula for documenting acceptance criteria, which can easily be translated into test cases.
My first contact with this approach was a couple years ago, when I started to use TDD on my projects with Martin Fowler’s “Given-When-Then” style of representing tests. The translation from user story to functional test was and is a perfect match.
But, what should we write?
Ron Jeffries came up with a formula, the 3 C’s. Although this formula came from Extreme…
