How I demo user stories

At DrDoctor we are broadly speaking following the Agile Scrum methodology; we do Sprint planning, work on user stories, hold retrospectives etc…

Where are break away from the traditional ‘sprint’ methodology is how we go about getting stories “accepted” and released. Traditionally in Scrum you demo all the stories at the end of the sprint in the Sprint Review meeting, whereas we tend to demo stories (and have them accepted by the PO) as they are completed and then we aim to have accepted stories released to production within 3 days.

Part of getting a story accepted is demonstrating the new functionality to the product owner.

Why you should strive to give a good demo:

• Gives the product owner confidence that you have delivered what they requested
• Gives you an opportunity to explain the nuances/subtleties of how you have implemented the story
• Gives you an opportunity to impressing the product owner - who doesn’t like impressing people?

How I demo a story (after I consider it code complete):

1. Prepare and practice - I work out how I’m actually going to demo the story, this might be by writing some SQL scripts to set up the scenario, or just knowing which website to start at and then I do a practice run through. I consider this step critical, a smooth demo means the PO can focus on the functionality and not my clumsiness
2. Ask the product owner - “can I demo to you?”, this sets the context so they know exactly what I’m talking about
3. Read out story requirements from Pivotal Tracker - Once I have the product owner at my desk, I always bring up the story and show them what was requested and talk through the requirements as they are written.
4. Explain:
   1. The approach taken during development - trying to keep it as high level as possible, whilst also explaining what was done to implement the story
   2. How I’m going to demo the story
5. Do the demo
6. Refer back to the story in Pivotal Tracker - after I’ve finished the demo, I go back to Pivotal Tracker to ensure we have covered off all the acceptance criteria from the story, and I explain any issues or subtleties they should be aware of
7. Call to action - I always ask them to accept the story straightaway. This forces them to either ask for minor changes or to accept the story.

The key thing for me as a developer is to ensure that I’m prepared. This means being prepared to do the demo, but also prepared to explain the details of the implementation and any subtleties the product owner needs to be aware of.

The other key is the call to action - “Can the story be accepted? Great, please mark it as accepted”.

Let me know in the comments: How do you demo stories? What do you think is missing from the list?