What makes a Story?

By David Yancey

The Story

A User Story, often considered a conversation starter, shifts the focus away from technical requirements and toward business-driven features and value. Mike Cohn, founder of Mountain Goat Software, defines a user story as:

“A user story is a short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.”

The user story format is designed so that the team knows the “who”, “what”, and “why” for each feature or set of features that are to be delivered.

As a <<the who>> I would like <<the what>> so that <<the why>>

Ex.

As a facility administrator
I would like a billing report for my facility
So that I can balance my month-end reports

A couple of key points here:

The “who” is the stakeholder and preferably the business/end user. This will generally never be stated as an engineer, analyst, or product owner, with the only exception being when we create a ‘technical debt’ story (which should only be on rare occasions).

The “what” is the feature that is to be developed, as stated in business terms, not implementation. The reason for this is twofold: first, to highlight the business value of the request, and second, to serve as a conversation starter. Implementation is more focused on the “how” rather than the “what”.

The “why” is where the value is understood. According to Simon Sinek, author of “Start with Why,” the why of what we do defines the purpose. When we know the purpose, then understanding the “what” and deriving the “how” becomes easier.

Acceptance criteria

The acceptance criteria are what the stakeholders will be looking for to consider their request is ‘done.’ Stakeholders typically convey these criteria to the product owner. Each criterion should focus on validating the 'why' and avoid implementation details. Each criterion should also be describable as a use case statement and used as a test case script, preferably in the “Given/When/Then” format.

The Gherkin or “Given/When/Then” format also follows a business value approach to describe a use or test case. Given a situation, When a trigger happens, Then output is expected.

Ex.

Given a billing report is requested
When a specific facility is part of the request
Then the report shows entries only for that facility

Technical Details

Within the Technical Details is where we describe the implementation. We identify the technical details during the design session for the feature and then the story. During design discussions, we identify 'known unknowns'—things we anticipate needing to research—and 'unknown unknowns'—potential challenges we have not yet foreseen.

The Slice

Often, a story initially exists at an epic or feature level, meaning it includes multiple deliverables or spans multiple sprints. If so, the team should break it down into smaller deliverables, each providing a 'potentially shippable' product.

The slice itself needs to follow the I.N.V.E.S.T. model for stories and preferably a vertical slice, or one that crosses all layers.

I.N.V.E.S.T.

I. Independent -- Stories should be as independent as possible.

N. Negotiable – A story is not a contract but rather a conversation, with the result of the story being the result of a negotiation between the stakeholder (or representative), the developer(s), and tester(s) at a minimum.

V. Value – If a story lacks a clear business value, it should not be pursued. Even technical debt stories should have an indirect ('dotted line') connection to business value.

E. Estimable – A story should be estimable/sizeable. If a story is not sizeable so that it can be prioritized, then it should be either sliced thinner or the team needs to do a spike/poc on the story. The spike/poc should be timeboxed with a defined deliverable for said spike/poc

S. Small – A story should fit inside a two-week sprint. At most, it should take 3 to 4 business days to complete. If a story is taking longer than estimated during the sprint, the team should be notified as soon as this becomes apparent, allowing for a risk assessment and necessary adjustments.

T. Testable – Every story must be testable at some point. Following the concept of Shift-Left Testing, testing begins early in the development cycle rather than being an afterthought. This starts with the acceptance criteria, which should be written in the Gherkin format for readability and use in test cases. Additionally, developers should employ Test-Driven Development (TDD), Test-While Developing (TWD), and Acceptance Test-Driven Development (ATDD) methodologies to ensure robust validation throughout the development process. With these practices in place, completed stories will have unit test coverage integrated into the CI/CD pipeline, ensuring continuous verification and deployment readiness.

Conclusion

By treating each user story as a conversation starter, teams align on expectations, prioritize effectively, and deliver high-value features within each sprint. This shared understanding fosters collaboration, ensuring that each increment meets both business needs and technical feasibility.