Ben Petersen

Demo stories to clients can be tricky, I highlight what has worked for me
code | 2016-05-06
Tags: Software Agile Demo
2016-05-06

Demo stories to clients can be tricky, I highlight what has worked for me

Sounds easy, right? Getting it right can be interesting.

Summary:

The “correct” way to demo a story to your client can sometimes be tricky, especially if you're new to agile or the relationship with them is spotty. Let this time be where you SHINE!

Focus on what the user saw or will see, not necessarily why it occurred.

For instance, your logic of storing a cookie could be incorrect, rows weren’t saved correctly, etc. There was a bug that caused the user to see a screen they aren’t used to.

Usually the user you're demo’ing the story, knows the background behind the story because it’s not just you they’ve heard this from.

Few tips that I do when talking about the story.

Say hello, - If you're on a voice only call, I say the following - “Hello, this is Ben and I will be demoing 4 stories. The first of which is Story-####” - Say the Story number and a short description of it - Example: Story-#### Long term fix for xxx The original issue was that our Chart Image API errors out due to a missing image. We believe this occurred when cleaning up the API project and this was accidentally removed. The fix was to add the image back in. - Skip the details here, questions after you show them are okay - Follow Steps to Reproduce it - As you can see the ... - If your concerned about it not being able to show it during the demo. Have a screenshot and a direct link if they'd like to try - Do you have any questions

The questions they may have may be detailed, or questions completely unrelated to the story. Have an understanding of the page around it, or know a team member who has worked on it.

Random thoughts:

  • Show your hard work, but also be concise, because the goal is to explain, have them understand, see your fix, and accept your story.
  • Clients, CIO’s, or team leads generally know details based on what users saw, so explain it to them like that. Not necessary why it occurred, but what the fix is and how it will impact or assist users. Don't go into detail on WHY it occurred. Overall goal: Answer questions they may have ahead of time. I’ve said it before, but it’s not said enough. Make yourself shine.
  • Sometimes there isn’t an easy way to reproduce the issue without developer tools open, skip the in-depth details, if they want to know the details they WILL ask.
  • Normally showing a SQL Proc output will confuse them and you’ll end up stating what they are looking at anyways. Don’t confuse them. If they want to be shown, they’ll ask. You may not be ready, but it’s a lot of effort to show a backup proc working correctly and I don’t think it’s worth it.
  • I’ve shown CEO’s, Team Leads output of sql queries. But often, this doesn’t matter as much as you think it does. Remember, what matters to them?