These next couple of posts will take things down to the most basic of Agile requirements: the User Story. A User Story is a tool used in the Agile development methodology to capture a description of functionality from an end-user perspective. The user story describes the type of user, what they want and why. It helps to create a simplified description of a software requirement.
User Story is a brief statement of intent that describes something the system needs to do for the user. We write them to relate business objectives and value:
As a <type of user> I want <some goal> so that <some reason> As a <user> I want <objective> so that I can <benefit>
The Role: provides segmentation of product functionality (one thing may behave differently for an accountant versus the CFO). Understanding user roles and how different users wish systems to behave is at the core of user Personas which is an Agile technique for categorizing users. The Activity: represents the system requirements for the role. But they’re not detailed requirements. They focus more on user interactions or objectives (written in business terms). Benefit: communicates why the activity is needed (business value, or enabler).
Some key points as they relate to User Stories are:
Mostly written by the Product Owner since they represent what the end-user needs and it linked to the product roadmap and vision.
User Stories are Not Requirements
Not detailed specs: negotiable expressions of intent
Short, easy to read, understandable
Small increments of valued functionality
Relatively easy to estimate
Organized in lists that can be rearranged
Not detailed at the outset, more detail is derived the closer to execution
Serve as inputs to other system documentation
BEST PRACTICES FOR WRITING USER STORIES
Good user stories follow Bill Wake’s INVEST model. They’re Independent, Negotiable, Valuable, Estimable, Small, and Testable. The ‘small’ requirement drives us to split large stories. But the stories after splitting still have to follow the model.
Independent: developed, tested, and potentially delivered on its own (i.e., a product might display a single record, then the whole list, then sort the list, then filter the list. That could be four separate (independent) stories (or not, if the complexity and effort are low).
Negotiable: not a contract, placeholder for requirements to be discussed, tested and accepted (i.e., the nature of the story promotes discussion with the customer where they and the team can better understand the goal so the “negotiation” is more subtle and is an agreement with the customer (you’re partnering).
Valuable: supports the team commitment to providing value to the customer as decided by the product owner (i.e., A story is a multi-layered cake (network layer, persistence layer, logic layer, presentation layer). To provide value we slice vertically through the cake with each story and complete that piece of work).
Estimatable: small enough to provide an estimation of complexity (and ability to task out) (i.e., at a minimum determine that it can be completed in a single iteration. If too large to estimate, then break it up into smaller stories. If too uncertain, then consider a technical spike).
Small: can be completed in a Sprint/Iteration (i.e., queuing theory indicates that fewer, smaller stories in a process will come out faster (for more on this topic please attend the training session “Backlog Grooming Techniques”).
Testable: all code is tested code (i.e., if the story is ill-formed, overly complex, too dependent on other stories, then the team may struggle devising tests).