Exciting. Entertaining. Do these words describe your sprint demo meetings? Or are boring and unfocused more accurate?

I can’t believe how many times I’ve come in to coach a team and they’ve been surprised when I actually expected to see a software demo in the sprint demo meeting. As the agile principle says, “Working software is the primary measure of progress.” Let’s see some software!

Why are so many agile teams so hesitant to do demos? Why are demos so lifeless? Sometimes, the team’s not actually done. That makes a demo awkward. Other times, they can’t communicate what they did to the Product Owner; they don’t speak “business.” But most often, they simply don’t know how to give a good demo.

So, how do you give a good demo?

Here are a few tips:

• Focus on acceptance criteria. You’ve defined what done means for the story (right?), so focus your demo around proving that you’re actually done.
• Start with the demo in mind. Don’t wait to think about the demo until you’re done with the story. You might be able to write tests that double as demo scripts. And it’s best to plan your demo for a story while it’s fresh in your mind, before you move to the next story.
• Prepare. Don’t ad lib. Think through an interesting scenario to prove that you’ve satisfied the core acceptance criteria. Create any necessary test data. Use tools like Watir if necessary to get your app into a state where you can start an interesting demo.
• Practice. Run through the demo at least once. When you’re getting started, you might want to grab a trial version of Camtasia and record yourself giving the practice demo. Painful, huh? That just means you need to work on it.
• Tell a story. Center your demo around a realistic user solving a real problem. The point is not just to show that the software works, but to show that it’s valuable.
• Keep it short. If you work on your stories one at a time and get them accepted when they’re ready, you don’t need to exhaustively cover all your acceptance criteria in your demo. Instead, focus your demo on what’s interesting and what’s valuable about each feature.

The sprint demo should be the most exciting part of Scrum. It’s when the team gets to show everyone all the value they’re delivering. That’s worth investing a little time to do well. You may find that previously disinterested stakeholders start coming just for the show.

What has worked well for you in sprint demos? What hasn’t worked? Share in the comments.

Related posts:

1. A Common, but Bad, Idea
2. 7 Tips for a More Effective Daily Scrum
3. Free Agile Product Management Seminar – Nov 11, Denver

At my current client, we’ve decided to use WatiN, largely for the C# vs. Ruby reason I discussed earlier this week. After spending a week working with WatiN (following a year of rarely using it), I’m impressed. Ruby and the active Watir community still have their advantages. But WatiN has really come into its own with C# 3.0 features like lambdas. I’m pleased with the test code we’re producing in terms of readability, speed, flexibility, and maintainability. I’ve proposed an Agile 2009 tutorial session on the patterns I’m using to get those results, and I’ll post more on that topic here soon. (Which will hopefully help with one of WatiN’s shortcomings—documentation.)

Related posts:

1. Web Testing for .NET Teams: WatiN or Watir?

I’ve noticed a pattern with several of my .NET clients who want to get into automated acceptance testing for web applications. They like the idea of WatiN because it would let them write tests in the same language as their production code. But then they notice that there’s much more documentation and apparently a much more active community around Watir. And that Ruby language looks interesting too. What to do?

I think there are good arguments for both. Here are the major pros and cons from my perspective…

WatiN

Watir

The Bottom Line

On balance, I think Watir is the better tool, has the better documentation, the most active community, and the best long-term prospects. But I understand the desire to standardize on C# or VB.NET for both production and test code. The long-term cost of adding another language to a product is not something to ignore.

Personally, I’ll continue to use and teach both tools with clients. When it comes to my own projects, however, I’ll be using and extending Watir, for all the reasons above and simply because I enjoy working with Ruby.

Which do you use and why?

Related posts:

1. A Common, but Bad, Idea
2. UI Sketches for Distributed Teams

Please don’t do this:

It will hurt. Not right away, but around sprint 4 when the bugs found in sprint 3 for the stories built in sprint 2 need to be mixed in with the stories planned in sprint 3 for sprint 4. And then it’ll hurt more in sprint 5 and later when you have to start regression testing more and more code each sprint.

Instead, just do as much work as you can get really DONE in each sprint. Plan it, build it, test it, and deliver it. It’ll be hard to ensure that testing doesn’t get squeezed out the back of the sprint. It will. When that happens, try moving testing to the front of each story. Create your test cases as specifications and then do just enough development to make them pass. (Consider a tool like Cucumber for this, using it to drive Watir if you’re building a web app. Or look at Fit/Fitnesse if that’s more your style.)

Related posts:

1. One Word Can Change Your Daily Scrum
2. Making Velocity Granular Enough