“Wants to”: Here we’re describing their intent - not the features they use. We understand how that person works, how they think and what they feel. We’ve hopefully interviewed plenty of MarkW’s. Our team should have a shared understanding of who MarkW is. “As a ”: Who are we building this for? We’re not just after a job title, we’re after the persona of the person. User stories are often expressed in a simple sentence, structured as follows: Once the user stories are clearly defined, make sure they are visible for the entire project team. Since stories should be deliverable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic. Time - Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. No need to guess at Agile stories when you can source them from your customers. Listen to feedback (be collaborative) - Talk to your end users (do it with them and not to them) and capture the problem or need in their words.

Ordered Steps - Write an Agile story for each step in a larger process (also called an EPIC). User personas - For Whom? If there are multiple end users, consider making multiple Agile stories. Outline subtasks or tasks - Decide which specific steps/ items need to be completed and which resource is responsible for each of them. The Definition of “Ready” (DoR) - The story is generally “ready” when the Product Owner is happy that the story can be placed on the Agile backlog as it fulfils all the construct parameters for a well-formed story item.

The Definition of “Done” (DoD) - The story is generally “done” when the end user can complete the outlined task, but make sure to define what that outlined task is. Ensure that you add Sufficient Agile Story DetailĬonsider the following when writing user stories:

Teams planner