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?

Agile Coin Game – Step-by-Step

🎯 Objective

To illustrate the importance of continuous delivery and customer satisfaction in agile development through a simple coin stacking exercise.

🧩 Step-by-Step Instructions

Step 1: Initial Coin Stacking (Waterfall Approach)

• Divide participants into two teams: Agile and Waterfall.

• Each team has roles like requirements gatherer, designer, developer, tester, and marketer.

• Waterfall team: Stacks all coins before passing them to the next person.

• Agile team: Passes each coin individually as soon as it is stacked.

Step 2: User Feedback

• The facilitator (acting as the user) reviews the coin stacks and provides feedback.

• Agile team adjusts based on feedback continuously.

• Waterfall team adjusts only after completing the entire stack.

Step 3: Second Coin Stacking (With Requirements)

• Teams repeat the stacking, but now the user provides specific requirements during the process.

• Agile team incorporates feedback immediately.

• Waterfall team must wait until the end to make changes.

Step 4: Comparison and Reflection

• Compare the results of both teams.

• Discuss how continuous delivery and feedback improved the agile team's outcome.

📜 Agile Principles Demonstrated

• Customer Satisfaction: Early and continuous delivery of valuable software.

• Welcome Change: Even late in development, change is embraced.

• Continuous Delivery: Frequent releases with a preference for shorter timescales.

• Collaboration: Daily cooperation between business and development teams.

• Reflect and Adjust: Regular reflection to improve effectiveness.

✅ Key Takeaways

• Early and continuous feedback leads to better outcomes.

• Agile teams adapt to change more effectively.

• Continuous delivery improves product quality and user satisfaction.

• Collaboration and iteration are core to agile success.

Agile Draw a House Game – Step-by-Step

🎯 Objective:

To illustrate the importance of continuous user feedback and collaboration in agile development through a simple drawing exercise.

🔹 Step 1: Initial Drawing (No Requirements)

• Instruction: Participants are told to "draw a house" with no further details.

• Time Limit: 1 minute.

• Outcome: Everyone draws based on their own assumptions.

• Agile Principle Highlighted:

• "Working software over comprehensive documentation"

• "Customer collaboration over contract negotiation"

🔹 Step 2: User Feedback

• The facilitator (acting as the user) reviews the houses.

• Provides feedback like:

• Doesn’t like chimneys (ecologist).

• Likes bicycles, dislikes cars.

• Agile Principle Highlighted:

• "Business people and developers must work together daily throughout the project."

• "Welcome changing requirements, even late in development."

🔹 Step 3: Second Drawing (With Requirements)

• Instruction: Redraw the house, but this time the user gives 3 specific requirements while participants are drawing:

1. Lots of windows (loves looking outside).

2. Big garden (keen gardener).

3. Eco-friendly features (e.g., solar panels, lean-to for a bike).

• Time Limit: 1 minute.

• Outcome: Drawings are more aligned with user needs.

• Agile Principle Highlighted:

• "Deliver working software frequently, from a couple of weeks to a couple of months."

• "Continuous attention to technical excellence and good design enhances agility."

🔹 Step 4: Comparison and Reflection

• Participants compare their first and second drawings.

• The facilitator discusses how the second round better met their expectations.

• Agile Principle Reinforced:

• "The best architectures, requirements, and designs emerge from self-organizing teams."

• "At regular intervals, the team reflects on how to become more effective."

✅ Key Takeaways:

• Early and continuous feedback leads to better outcomes.

• Assumptions without user input often miss the mark.

Agile is about iterative improvement and collaboration.

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! 👇

SQL CONVERT Function

Syntax 
CONVERT(data_type(length),expression,style)

SQL Query
UPDATE HS_HR_EMPLOYEE
SET EMP_EPF_NUMBER = CONVERT (VARCHAR (20),CONVERT(NUMERIC,NSSF_NUMBER))
FROM AAA_NSSF_NO_UPLOAD
WHERE HS_HR_EMPLOYEE.EMP_NUMBER = AAA_NSSF_NO_UPLOAD.EMP_NUMBER

SQL Server 2008 Process Information

By using the SQL Server Activity Monitor you can know the SQL Server processes and how these processes affect the current instance.