User stories are short, simple descriptions of a requirement told from the perspective of the person who would like a new feature. They typically follow a common template that is used to foster alignment with the work at hand and is not limited to tech or agile teams.
The beauty of this sentence is that it concisely summarizes:
- Who it’s for
- What is being built
- Why it’s being built
User Story Format::
As a <type of user>, I want <to perform some task> so that I can <achieve some goal>
Acceptance criteria ::
Given that <some context>, when <some action is done>, then <such outcomes are expected to occur>.
Acceptance criteria explain what has to be done for the user story to be marked as complete. They’re commonly referred to as scenarios or detailed explanations of what has to be done. You can have multiple scenarios per user story.
Prioritization is an art and science. Depending on what tool you use, you probably have seen the following matrixes or something similar.
What about stretch goals, notes, and estimations?
Estimations or story points are used to estimate the difficulty of implementing a given user story. Scrum masters or product owners use this to measure velocity or the amount of work finished by the team in each sprint. It becomes an important metric used during retrospection and sprint planning because eventually, we will see the capacity of what can realistically be done within a certain timeframe.
Fibonacci numbers (1, 3, 5, 8, 13, 21, …) are frequently used to provide estimations because it forces teams to provide relative estimates. For example, it’s easier to distinguish five vs eight then five vs six. There are many creative approaches to providing estimations like using dog breeds or vehicles. I personally like using t-shirt sizes.
User Story Template
Title: <What this user story is about>Story
-----
As a <type of user>,
I want <to perform some task>,
so that I can <achieve some goal>.Acceptance Criteria
--------------------
Scenario A: <What should happen>Given that <some context>,
when <some action is done>,
then <such outcomes are expected to occur>.Stretch Goals
--------------
<optional>Notes
-----
<optional>Priority: <Highest, High, Medium, Low, Lowest, Unprioritized>Story Points: <1, 3, 5, 8, 13, 21, ... >
Example (*)
Title: Returns and exchanges go to inventory. ----- Story As a store owner, I want to add items back to inventory when they are returned or exchanged, so that I can track inventory. -------------------- Acceptance Criteria Scenario 1: Items returned for refund should be added to inventory. Given that a customer previously bought a black sweater from me and I have three black sweaters in inventory, when they return the black sweater for a refund, then I should have four black sweaters in inventory.Scenario 2: Exchanged items should be returned to inventory. Given that a customer previously bought a blue garment from me and I have two blue garments in inventory and three black garments in inventory, when they exchange the blue garment for a black garment, then I should have three blue garments in inventory and two black garments in inventory. -------------- Stretch Goals - How can we automate the exchange or return process?Notes ----- - We currently process returns by ... - We currently process exchanges by ...Priority: MediumStory Points: 8
API User Stories with examples
TechTalk 