How to make User Stories cool

Sii
BlogerSii
How to make User Stories cool

How to master passing valuable business needs to developers?

Step-by-step guide

User story is implemented with pattern:

As a <user type>, I want to <function> so that <benefit> .

Examples:

As an enterprise reader, I want to buy premium content so that I get more specified and valuable information.
As an enterprise, we want our readers to be logged into all our services so that they can use one account to get access to all our services.

User story is defined incrementally, in three stages:

The brief description of the need (a good practice is to put value and priority into the story).
The conversations that happen during backlog refinement and iteration planning to solidify the details.
The tests that confirm the story’s satisfactory completion.

Well-formed stories will meet the criteria of Bill Wake’s INVEST acronym:

Independent	We want to be able to develop in any sequence.
Negotiable	Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement.
Valuable	Users or customers get some value from the story.
Estimable	The team must be able to use them for planning.
Small	Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration.
Testable	Document acceptance criteria, or the definition of done for the story, which lead to test cases, how story should be tested.

Try to avoid the generic role of User when writing user stories

User stories are about all of the role who interact with the system or who realize some value or benefit from the system.
Not all actors are end users.
It may be useful to create aggregate roles (such as consumer) and specialized roles (such as browser or frequent shopper).
Avoid putting solution instead of function.
If benefit sounds funny, probably user story is not valuable.
Too formal or too much detail.
Product owners with good intentions often try to write extremely detailed user stories. If a team sees a story at iteration planning that looks like an IEEE requirements document, they often assume that all the details are there and will skip the detailed conversation.
Technical tasks masquerading as stories. Much of the power of Agile comes from having a working increment of software at the end of each iteration. If your stories are really just technical tasks, you often do not end up with working software at the end of each iteration, and you lose flexibility in prioritization.
Skipping the conversation. Stories are intentionally vague before iteration planning. If you skip the acceptance criteria conversation, you risk moving in the wrong direction, missing edge cases or overlooking customer needs.

What size should a User Story be?

A story should be small enough to be coded and tested within an iteration – ideally just a few days.
Large User Story is called Epic.
Backlog items tend to start as epics when they are lower priority. For sprint planning, epics should be broken down into smaller chunks, but not so small that you have moved into detailed design.

How detailed should a user story be?

Too broad

A team member can view iteration status.

Too detailed

A team member can view a table of stories with rank, name, size, package, owner, and status.
A team member can click a red button to expand the table to include detail, which lists all the tasks, with rank, name, estimate, owner, status.

Just right

A team member can view the iteration’s stories and their status with main fields.
A team member can view the current burndown chart on the status page, and can click it for a larger view.
A team member can view or hide the tasks under the stories.
A team member can edit a task from the iteration status page.

When do I add detail?

Acceptance criteria provide the Definition of Done for the story. As details about the story evolve, capture the critical ones as acceptance criteria.

The PO should list as many acceptance criteria as possible in order to clarify the intent of the story.