Identifying software requirements is hard!

Users rarely know what they want software to do, and even when they do, they can rarely communicate it in a way that ensures consistent understanding with the developer.

A story is a way to document requirements from the perspective of the end user.

Stories evolve. They start in the format:

“As a <user type>, I want to <do something> in order to <get some benefit>”

As such, in one short sentence, they identify who the user is, what they want to do and why they want to do that.

Start thinking of software as solving problems for real people, make them tangible, don’t use the word “user”.

Stories should stay like this, high-level and short, until they are released into a sprint following the Just In Time (JIT) principle. Rather than making all the decisions up-front, make decisions based on the information you have at the latest possible moment before development of that story begins.

At this point, they will be expanded to cover more detail, de-composed into smaller, more manageable pieces of work, acceptance tests will be written that define what must happen for a story to be done and they will be estimated (more on this in another post).

Stories should be written by the whole Scrum team during a brainstorming session where you write as many stories as possible. They can be prioritised later. Some stories will be implementation-ready (need no further decomposition, be of suitable complexity etc etc), others will be epics.

Epics are stories that include too many variables to really know how big they are, or when a team can’t settle on an appropriate estimate, or when its requirements are known, but its effort is off the charts. Epics get decomposed into stories that require between 0.5 days and 1.5 days to complete.

Stories should follow the INVEST priciple, which stands for Independent, Negotiable, Valuable, Estimatable, Small and Testable.

• Independent
  The story should not be dependant on any other, as this 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.
• Negotiable
  Stories should have room to negotiate – they are a starting point, not a contract.
• Valuable
  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.
• Estimateable
  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.
• Small
  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.
• Testable
  The implementation of the story needs to be testable. Define the tests that can be performed to validate the story was correctly implemented.