Sprint Review. Cheater, cheater, cheater!
I have just been accused of cheating at last week’s sprint review. Let’s see what you think.
The way our sprint reviews work, everyone in the company gets to rotate between teams who show their work in 15 minute segments. Picture a science fair with parents moving between booths and spending 15 minutes at each one. This has been a hugely successful format because teams get to have more intimate conversations with people seeing their work. Discussions are more interactive because there is a smaller group watching the demo and folks are more likely to speak up.
From the presenter’s point of view, this is showing the same thing 4 times in a row. This is okay, but gets a bit tedious. Worse, because each group brings up individual issues there may be things about the feature that get skipped in a given 15 minute segment.
What I Did
I recorded a feature walk through on Camtasia and played it during sprint review. Four times. This left 3 minutes for discussion, but with the transition times, it pretty much took up the entire 15 minutes.
The most common feedback was, “Cool idea. It was too long.”
Noted. And, I think the idea of doing a complete walk through as a recording has merit because it sort of forces that all areas I want to show will get shown.
It is important to realize that I made the recording a mere hour before Sprint Review. Thus, the software was real and did do what I showed.
What I Will Do Next Time
- Limit the Camtasia video to 5 minutes and leave plenty of time for discussion.
- Be more animated. No monotone voice.
Your Thoughts? Am I a big, fat cheater?
I vote for *not* a cheater. But I think the high value that agile places on collaboration and face to face personal communication makes the practice of prerecording a demo seem, well, impersonal and perhaps not the most impactful means of communication if you have the opportunity to demo in person. Live demos will always trump canned ones for the “wow” factor in my experience.
I think your idea of limiting it to a 5 min demo is good, and would make doing it 4 times less tedious and more interactive as it leaves more room for questions (less is more is this case). If you don’t want questions until the end then you could ask people to save them until you are done (writing them down if necessary), since they will not be waiting more than 5 mins to get an answer.
If you are worried about not showing everything that you want to show then why not follow a basic hand-written script?
Paul.
A short video sounds like a good overview to make sure people see everything included in a feature. After that, I would imagine most customers and team mates are going to want to grab the mouse, try it a bit, and ask questions.
As Paul said, the real value is in having a prepared script so that you can efficiently give a demonstration without forgetting anything.
lol… CHEATER!
Na… I also vote for NOT Cheater.
“Art of the possible” and if I’d have to show the same demo/feature walkthough 4 times right after the other it would be possible that I’d have to kill someone… :p
I think the important point is the intent. The intent was to not waste time. To provide the same experience for all four shows and it wasn’t to hide anything. And given that the demo was based on working, shippable code… (and if challenged you could drop into the app and just do it)
I think you were being smart and efficient.
But yes, as you and Paul suggested, I think the shorter video overview and an ah-hoc demo of the app based on feedback/questions from the current people in the group.
But then again, since I’m SUCH a Scrum noob I could just be talking out my a……
😉
I was there and I think it was a cool experiment! However, I think something is lost when you cannot see the person presenting live, see his expressions and so on. I agree that it was too long, but I am just wondering if it is really worth it for a five minute segment. As a listener I would definitely prefer a live presentation. It would also allow you to quickly elaborate on certain features that a person is interested in, because you have the real application context there on the computer as opposed to some video viewer.
what an awesome way to do sprint reviews, and I think the recording is a great idea – I can picture it working really well in other sprint review formats as well.
You know, it might be fun to keep an archive on a project wiki or something – it’s so easy to forget how far we’ve come sometimes when we’re dealing with the day-in/day-out. It could be cool to be able to occasionally pull out “look where we were just last quarter”.
And just the fact that you were able to put it together so quickly is perfect (I’d be worried people would obsess over getting it just right and so spend a bunch of time on it).
(oh, and BTW, NOT cheating… check out scott berkun’s post on the irony of creative change – I think what you did can fall neatly into that category 🙂 http://www.scottberkun.com/blog/2008/the-irony-of-creative-change/)