How To Write Good Requirements / User Stories In Scrum

Consider that 70% of software projects fail due to poor requirements. The estimated rework associated with these failures exceeds 45 billion USD annually.

The question is – why is this happening? The answer is twofold. First, business requirements tend to lose focus on the customer; and second, the requirements lack a holistic frame of reference that enables requirements analysts to drive and trace requirements from customer need, through strategy, and down to the solutions being implemented.  (http://stevbros.com/blog/80-new-products-fail-70-of-software-projects-fail-due-to-poor-requirements.html)

In order to write good requirements, or user stories, follow these steps:

1)  Define as many personas as you can representing the users of your system.  This will help you to focus on the customer, as well as driving and tracing requirements from customer need.  A persona, first introduced by Alan Cooper, defines an archetypical user of a system, an example of the kind of person who would interact with it.  A user does not have to be or represent an individual.  A user can also represent an organization.

2)  Make sure that your user stories fit the “3 C’s”:

• Card – should fit on index card or post it note
• Conversation – get details from Product Owner
• Confirmation – to make sure it was implemented properly. User Acceptance Criteria must be met.

3)  Split user stories so they are the appropriate size to be included in a sprint.  Some ways of splitting a story include:

• Split by process step
• Split by input/output channel
• Split by user options
• Split by role
• Split by data range

4)  Have each user story follow the INVEST mnemonic:

The INVEST mnemonic for Agile was created by Bill Wake as a guideline to follow to ensure a good quality Product Backlog Item (PBI), typically written in user story format.

Independent:  Stories should be as independent as possible.

Negotiable:  A story is not a contract.  A story IS an invitation to a conversation.  The story captures the essence of what is desired.

Valuable:  If a story does not have discernable value it should not be done.

Estimable:  A story has to be able to be estimated or sized so it can be properly prioritized.

Small:  Two week iterations which allow for user stories to average 3-4 days of work – TOTAL!  This includes all work to get the story to a “done” state.

The smaller the user story, the higher the accuracy of the estimate!

Testable:  Every story needs to be testable in order to be “done.”