User Stories
User stories are an integral tool in the agile methodology. They are a representation of the customer need and are expressed as a small, concise statement of a feature needed to deliver value. User Stories facilitate interaction and can be used as a basis for discussion.
As a new product owner, I wrote poor user stories. Poorly written user stories can put a project at risk. These errors have helped understand what a user story should not look like. They include:
- Putting requirements after the ‘So that..’ section instead of the value to be derived from the story.
- Writing user stories with technical requirements e.g. A story that begins with ‘As a developer..’ is technical and can be written in clear English.
- Writing user stories with too many details, almost describing the ‘how’. This inhibits developers’ creativity.
A good user story should follow the 3C’s — Card, Conversation, and Confirmation.
- Card: The title and format are two parts of a user story. A title should succinctly summarize what the card is about: for example “Access for cash withdrawal”. There is no mandatory structure for user stories; however the most popular formats capture the ‘who’, ‘what’ and ‘why’ of a requirement.
Example format 1
“As a <role>, I need to <feature> so that <goal or value>.”
As a current bank account holder, I need to access my account, so that I can withdraw cash.
Example format 2
“In order to <business value>, as a <role>, I need to <behavior>.”
In order to withdraw cash from my account, as a current bank account holder, I need access to my account.
- Conversation: The purpose of User Stories is to stimulate communication between the product team. The user story intentionally does not capture all there is to know about the customer need. A well-written user story invokes conversation among the team.
- Confirmation: To confirm the delivered item satisfies the need expressed in the user story, an acceptance criteria is required. Acceptance criteria define the boundaries of a user story and help the product owner verify and validate the solution met the intended user need.
The INVEST criteria is a commonly used construct for ensuring quality in user stories. It calls for user stories to be:
- (I) Independent: represents a feature which can be delivered independent of other features. It is advisable that user stories that are dependent on another should not be added to the same iteration.
- (N) Negotiable: the team can negotiate how to deliver.
- (V) Valuable: expresses the value to the customer. Example: “Card PIN entry” allows only the correct person to access the account.
- (E) Estimable: team can estimate effort to deliver based on past experience.
- (S) Sized Appropriately: can the card be completed in one iteration? In general, the smaller the better.
- (T) Testable: can be validated objectively.
With user stories, more practice makes you better. In my next blog post, I will be writing about Job Stories.
