Guidelines for writing a good UserStory
We have been using Scrum to manage our projects for almost the past five months now. It has been working great for us so far and has helped boost team work and increased the morale of the entire development team. I think it has enabled the team to keep their eyes on the ball and keep making progress by avoiding unnecessary distractions. One thing I have been struggling with in the Sprint planning meeting are with writing the UserStories. I am finding it tricky to come up with good clearly defined UserStories from the discussions we have been having. The INVEST acronym from the “User Stories Applied” book by Mike Cohn I think should serve as a good guideline for defining UserStories. The following is from Doug Seven‘s take on INVEST.
INVEST stands for Independent, Negotiable, Valuable, Estimatable, Small and Testable.
The story should not carry with it dependencies, which can lead to estimating problems. Instead the story should be completely independent so that it can be worked on without pulling in a set of other stories.
Stories should have room to negotiate – they are a starting point, not a contract.
The story should communicate the value to a user or customer, not to the developer. The story should define not only what a user can do, but what value the user gets from the implemented story. If there is no value, cut the story.
You need to be able to estimate the amount of work required to implement the story. If it is too big and too daunting (an epic), break it up into smaller stories.
Similar to the previous, stories need to be small. Large stories are too complex to manage, and are typically more than one story compounded together.
The implementation of the story needs to be testable. Define the tests that can be performed to validate the story was correctly implemented.