Effective Story Writing in Scrum.

A major part of the Scrum Process is Story writing.  I decided to research the art of story writing so that I could improve my own story writing and hopefully improve the story writing capability of my team.

I discovered that all User Stories follow the same format.

As a <USER> I want <FUNCTION> so that <BUSINESS VALUE>

So as a Web based company, an example of a user story at my company could be: As a <NEW USER> I want to be able to <REGISTER> so that I can <USE THE WEBSITE>.

I then visited the Mountaingoat Software website for more information on story writing.  I found that they use an acronym to help users write better user stories. I N V E S T.  This stands for Independent, Negotiable, Valuable, Estimatable, Small and Testable.


The story being written should not carry any dependencies.  This could lead to estimating and prioritization problems.  An independent story can ideally be worked on without the need to pull in any other stories in order to complete it.


Stories should have room for negotiation between the Team and the Product Owner.  They are not a solid contract but some room for requirement change should be available.


The story being written must have some value to the users or customers, not the developers.  Stories should be written with the user or customer in mind.  The story should define what a user can do and what benefit this would bring to them if the story is implemented.  If there is no value to the customer or user, then the story should not be prioritized.


The Team should be able to estimate the amount of work that is needed to complete a story during estimation.  If the team are unable to estimate the story, due to ambiguity, the stories requirements should be made clear.  If the team are unable to estimate due to the size of the story, you will need to break the story down into smaller stories.


Stories should be Small and relatively un-complex.  Large stories by nature seem to be complex to manage and more often than not are 2 or more stories combined.  Large stories should be split up into smaller stories in order to make them more manageable.


Stories should be in a testable against a predefined test case to verify that the story has been completed effectively.

Hopefully this will

Published by The Daily Scrum

A CSP, CSM, CSPO who lives and works in Glasgow, UK.

%d bloggers like this: