How-To-Demo

Ever struggle to split a User Story? Most of us familiar with the industry standard “SPIDR” method (Spike, Path, Interface, Data, Rules) for splitting User Stories. But have you tried the "How-To-Demo" technique?

 The rule is simple: Reverse engineer your User Story at the end-of-sprint Demo. If you can't explain how to Demo your User Story in 3 steps or less, the User Story is too big. Split it!

 How to Apply:

·       The Happy Path: Start by demoing the Happy Path. Demo the simplest way to finish a task first. Handle edge cases, errors or alternative paths in the next Demos.

·       One Data Type First: Demo using only one data type before adding others. Support for other data types in later Demos.

·       Logic Over Style: Demo a basic UI to prove the logic works, then advance styling it in later Demo.

·       Simplify Rules: Ignore complex rules initially and show the basic functionality. Add the rule-based logic in a follow-up Demo.

·       Documents: Even finishing a piece of documentation or test cases can be part of your Demo goals.

 This approach creates a crystal-clear “Definition of Done” and ensures you always have something valuable to show and Demo.  It is s an easy way to keep your team focused and your sprints manageable. Try it in your next sprint!

3 Cs

During a knowledge sharing session I conducted on user story writing, I asked the audience: "What does a User Story mean to you?" The image below captures their responses.

As a Scrum Master, I believe the role is to facilitate the "3 Cs" to ensure stories deliver a value:

·       Card: A story is more than just a "As a... I want... So that..." template. It must contain enough detail to ensure the team knows exactly what to deliver and how to demonstrate that value.

·       Conversation: Must encourage continuous dialogue. It is about the team initiating discussions to clarify requirements and uncover the "why" behind the work.

·       Confirmation: This is about driving alignment on the "Definition of Done." What does success look like at the end.

I would love to hear your thoughts. How do you approach user stories with your teams?

Shifting Your Perspective on Backend User Stories

One of the most requested topics from my previous sessions was: How do we write better user stories for backend teams, specifically for APIs?

Here is my approach to handling "Technical" stories without losing the value of “User Story”

 1. Stick to the Standard Format 📝

Even for APIs, the classic structure keeps the focus on the "Who, What & Why":

• As a [frontend app / third-party developer / another API ]
• I want [to retrieve user data via an endpoint]
• So that [I can display the user profile to the end customer]

2. Identify the "Consumer" 🔌

Your user isn't always a human. It could be:

• A mobile app or frontend framework
• Another backend microservice
• An external partner's system

3. Define the Action & Value 💡

Be clear about what the API does (e.g., Create a new order) and why it is a priority. This helps the team validate the business impact of technical work.

4. Acceptance Criteria is Must ✅

This is where "Done" is defined. Some examples like

• Given a valid request token, When the API is called, Then return a 200 OK with User ID and Name.
•  Must handle 401 Unauthorized for invalid tokens.
• Specify rate limits and response formats (JSON/XML).

 

Finally Quick Tips for API User Stories: 🚀

• Mention HTTP methods (GET, POST, etc.) in the technical notes.
• Clearly define authentication requirements.
• Always link to the API documentation or swagger specs.

 

I would love to hear from you! How do you handle backend user stories in your sprints? Do you have any "secret sauce" for keeping them simple yet detailed?

Let’s start a conversation in the comments! 👇