Real Stories

Please don’t do this …

  • As a system analyst I need to produce a design for …
  • As a developer I need to write code to …
  • As a QA engineer I need to write test cases …

None of these are User Stories.

Let’s start from Agile Principle #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This means that our delivery process should look like:

The Agile Value Proposition
The Agile Value Proposition

User stories are a vehicle for delivering features in incremental units of demonstrable product behavior within a single iteration. The goal with user stories is to create something of value with the minimum amount of effort. Value means something a user would pay for. Thus a ‘story’ to create an API End Point is not a real story since it provides no direct value to a user.

By keeping individual stories small, teams can deliver value to users faster and with less risk by ensuring a smoother flow of shippable code.

WSJF - Explained
Keeping stories small maximizes delivered value

User story definitions always should include Acceptance Criteria. Acceptance criteria specify the minimum conditions — from the perspective of the user— that must be met for the user to actually realize the value described in the user story. Acceptance criteria may be described using a number of demonstrable scenarios, ideally structured with preconditions, triggers and output behavior. (Adoption of the BDD approach using Gherkin syntax is strongly recommended).

Writing good user stories is a foundational practice that one can improve over time. Consider this:

Great Stories >> Great Features >> Great Products

 

Print Friendly, PDF & Email