Story Theory

STORY

A Story is work that is broken down and put with other stories tell of a journey and show direction. The point of a story is to be a place of captured shared understanding that can be acted upon. The Story should be written by the Product Manager due to the duties of ensuring the backlog is prioritized and not bloated.

Here is how to write one: Title: Feature and a very short description Description: From the perspective of the user* should explain the functionality and for what reason. The format that I suggest is: AS A [USER] I WANT [FUNCTIONALITY] SO THAT [REASON]

Acceptance Criteria: This is what the PM will use to test whether a story has been implemented according to the understanding discussed during IPM and throughout the week. The format I suggest is: GIVEN [General setup and context] When [An something is perform] Then [result] AND/OR**

Artifact(s): Ensure any conversations, feedback, wireframes, design drafts, architecture are available. Any developer should be able to open a story after IPM and get to work, without having to go hunting or having to talk to many other teams/folks.

*Sometimes the user is a system by itself, and that is ok just have that system be the user. What I suggest is to have the developer themselves as the requestor or the "user". i.e. If an automation needs to be done that only the developer/implementer would be aware of say "As a product-developer I want..."

** Sometimes you will have a larger acceptance criteria and will need multiple things to occur in order to test. However, if too many things needs to occur there have been times where that is a sign that a story might be too big.