User stories

User story basics

User story communicates features for development team:

  • Who will need the feature, eg., recruiter using LinkedIn, project stakeholder using InvisionApp or lost driver using Waze.
  • What exactly user want to do, eg., search by address on the map, filter candidates for the position, make comments for the design iteration.
  • Why the action is necessary, that the team can see a broader context, eg., so that driver can find a way home, recruiter can quickly see top 5 executes for the position or stakeholder can return the work back to designer for further adjustments.

A detailed product backlog item which is ready for the sprint

Elements of a well crafted user story / task / issue / ticket which is ready for development:

  1. A good summary line which makes sense without opening the description.
  2. A good description which is focused on WHAT and WHY should be done from the users point of view. (If the story requires more tasks, then developers can create them additionally as separate tickets).
  3. Acceptance criteria — specific criteria to determine when the story is Done.
  4. Optionally: How to test, testing scenarios.
  5. Should include a reference to the “Definition of done”, which can be common for the whole component, sprint, project, team etc.
  6. Should include the estimate — whether in time or story points (or both), based on the followed practice in the team. This is necessary for sprint planning and monitoring the progress throughout the sprint.
  7. It should have a set priority.

“INVEST” criteria for backlog item

Here comes the all time classic which is still true for user stories:

  • I — Independent: We want to be able to develop in any sequence.
  • N — negotiable: Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement.
  • V — valuable: Users or customers get some value from the story.
  • E — estimable: The team must be able to use them for planning.
  • S — small enough: 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.
  • T — testable: Document acceptance criteria, or the definition of done for the story, which lead to test cases.

Readiness for Sprint

  • Stories must be small enough to easily be done in the Sprint.
  • Preferably each story take 1–3 days to get “Done”
  • Teams should take many Stories into each Sprint
  • Each Story should be a part of delivered Increment of functionality for the Sprint

Story templates

Typical template used:

  • As [user role], I can [do something] in order to [some benefit of purpose.
  • [User role] can [do something] so that [some benefit or purpose]

--

--

Product Management. Customer focus. www.rozentals.com

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store