Getting Started with User Stories

Why User Stories?

In Agile (software development and otherwise) we need suitable items to populate and pull from our backlogs. Well-constructed user stories balance the needs of stakeholders for valuable and meaningful pieces of functionality with the need of development teams for contextually relevant, but not overly prescriptive work items.

Relevant Agile Principles

Effective use of User Stories contributes to mutiple Agile Principles:

• Continuous Delivery of Value
• Welcome changing requirements
• Business people and developers work together daily
• Continuous attention to technical excellence
• Simplicity is essential

If you find that your User Stories aren't helping with these aspects, some reflection is in order!

What are User Stories?

User stories are ideally small chunks of functionality and have become the de facto standard for backlog items. When they aren't small we call them epics or features, and do out best to split 'em down.

The ideal user story satisfies the somewhat famous INVEST criteria (due to Bill Wake):

• Independent: user stories can ideally be developed in any order, allowing prioritisation of the backlog
• Negotiable: not over-detailed so as to allow co-creation between customer / stakeholders / product owner and the developers
• Valuable: it needs to be valuable to the customers or end-users
• Estimable: a rough sense of size (as well as value) is needed to prioritise the backlog
• Small: small items can be completed relatively quickly, enabling flow
• Testable: we want explicit criteria for completion, so we can tell when a story is "done"

Tip: Don't get too hung up on INVEST at first, but keep coming back to it as you build your intuition for what makes a good user story.

How to Create User Stories?

Old school user stories were fairly informal and followed the 3Cs:

• Card: Written on a 3" x 5" index card, by sticking to one side of a card they were necessarily brief
• Conversation: "The card is a placeholder for a conversation". The description on the card was intended to be elaborated through conversation between developers and the customer representative or product owner.
• Confirmation: The back of the card would sketch out minimal acceptance criteria or tests of completion.

Pros

• Rapid, lightweight, and tacticle
• Easy to sit down as a group and write cards individually, then combine and re-write

Cons

• The Conversation aspect practically mandates high domain knowledge and constant access to a customer representative or Product Owner

The newer school, arising from Behaviour Driven Development (BDD), is more formal. The User Story now describes Who?, What? and Why? to give more context, or (more formulaically):

"As [a] ... I want ... So that ..."

And the acceptance criteria are typically specified in Given [current state] When [event] Then [effect] format.

"Given ... When ... Then ..."

Pros

• Seems to work better for less experienced teams
• Lends itself to test automation (especially the Given When Thens)

Cons

• De-emphasises the Conversation aspect, which aids co-creation and iteration

Use whatever works. Try both (and try the other style periodically).

Who writes user stories?

User stories should be written collaboratively by the development team, the product owner and stakeholders.

Often it is delegated to Business Analysts, but their role should be more around facilitating and editing.

What else?

Small stories may be decomposed further into technical tasks, if this is useful for the development team.

Sometimes there will be a piece of work that is meaningless to end users and stakeholders, but makes sense as a cross-cutting piece. These often represent so-called non-functional requirements (NFRs) and that's ok. Often these pieces are referred to as technical stories or architectural epics. They should be the exception rather than the rule.

Other items can appear in product backlogs:

• Defects
• Spikes: short investigations
• Learning and improvement items

Rather than putting user stories straight into a backlog, they can be organised into a user story map. And that's a great move!