Sprint review Videos

In my last post , I talked about tips for live sprint reviews. One thing I didn’t mention was videos and how useful they can be …

Why record the sprint review?

Some of the key stakeholders might not be able to regularly attend the meeting (e.g. sales, consultants who are primarily on site with customers, …). Recording the sprint review, gives us a mechanism of capturing feedback, even if a stakeholder can not attend the live review.

Record live review or record separate demos?

Recording the live sprint review is the easiest and least time consuming thing to do. A great thing about recording the live sprint review is that it will include the feedback conversations. The drawback is that the video could be up to 30 minutes long and if the stakeholder hasn’t booked time in their diary to watch this, they make struggle to find that time. You could edit the video and split it up into 1 video per feature – a 5-10 minute video is much easier to squeeze into a busy day and watch.

Another approach is to record the feature demos as separate demos outside the live sprint review meeting. You could do this before the live meeting which doubles up as a practice run for the live review. You can end up with a good quality, to the point, video demos. The downside is that the videos will not include the feedback conversations. However, because the videos will not include conversations that might be sensitive, these videos will probably be more feasible to use as a mechanism to capture feedback from customers.

No live reviews – just videos

It is feasible not to have live sprint reviews in a few of situations:

  • When the key stakeholders regularly can not attend the sprint review meetings (e.g. sales, consultants who are primarily on site with customers, …). When you are at the stage where it is just the development team in the review meeting and maybe just one other stakeholder, it’s time to think of just doing videos.
  • When there are multiple product teams, each wanting a sprint review and stakeholders time. The different product teams could be asking the same stakeholders for their time. So, we are asking a busy stakeholder for a multiple of 30 minutes. Different teams may have the same product owner and same scrum master. So, the scheduling of the review meetings can be a challenge. In this situation, videos may be a better approach.
  • You may be doing kanban or scrumban rather than pure scrum where there isn’t a fixed sprint schedule. In this situation, you can do the videos immediately after a feature has been tested to capture feedback.

Who should do the video demo?

I prefer the developers to do the video demos. The developers will have worked hard to make the features and as a result, hopefully, some passion for the feature will come through in the demo. The product owner should help the developer script the demo to make sure it is targeted to the stakeholders.

Recording software

For recording live reviews, GoToMeeting works well. Camtasia works well for recording demos outside of the live review – it’s really easy to use and has great editing capabilties. Camtasia is a “paid for” product which I think is worth every penny but Jing is free and is a great start point. Jing is limited to 5 minute videos which actually forces the demo to be short and to the point.

Capturing feedback

A real danger with videos is that we lose the feedback – particularly if there is no live review. Remember the sprint review exercise is all about feedback, so, it is critical we get that with the video approach.

The product owner should drive the feedback, chasing stakeholders up for their thoughts.

Online collaboration software is critical with the video approach. You need to be able to upload the videos and allow people to post their comments against it. aCloud Collaborate works well, there are lots of other solutions as well.

Have you used sprint review videos? Have you found them useful?

Connect with me:RSSGitHubTwitterLinkedIn

Tips for better sprint reviews

In my post a few months ago on scrum, I briefly talked about sprint reviews being great for getting feedback from the wider business.

Here are some tips that I’ve found useful on sprint reviews …

Getting stakeholders in the door

One of the most challenging aspects of sprint reviews is actually getting stakeholders to attend. Here’s some stuff we can do to get people in the door …

  • Send a calendar invite for the sprint review a couple of weeks ahead of the sprint review meeting. The chances are that this will be a free slot for them at this point and will help avoid them booking something else in during the time slot. Make sure the invite is only for 30 minutes – it’s easier for stakeholders to justify a 30 minute meeting over a 2 hour meeting
  • Send an agenda a few days before the sprint review. This serves as a reminder to the stakeholders that the meeting is happening. Make the agenda engaging by reminding the stakeholders of the business value on the new features. Reiterate that the meeting will only last 30 minutes
  • Send stakeholders a sneak peak of some functionality the day before the sprint review – a screen shot of a new screen or 30 second video of a new feature. This again reminds the stakeholders of the meeting and helps engage them
  • Have a verbal conversation with key stakeholders who you really want there – “are you coming? we are really excited about feature X but really need your feedback to make the feature great for our customers”

Preparing

In order to get stakeholders to come back to the next sprint review, the meeting needs to be engaging and the demos need to be slick. It needs finish within 30 minutes as well. In order to do this, the team need to prepare …

  • A couple of days before the sprint review (before the agenda is sent to stakeholders), ask the team what they want to show at the sprint review. Make sure there is the right amount of content for 30 minutes
  • Ask team members to think about the content of their demos and script them. Ask the product owner to feedback on the scripts – we need to make sure the content is targeted to the stakeholders and to the point
  • Ask team members to practice their demos a fews times. This helps the demo in the live review run fairly smooth
  • Ask team members to practice their demo in the actual environment. So, try it on the actual machine, in the actual room, on the actual projector. Very often, the screens look very different on a projector and some last minute tweeking is needed

Opening the meeting

  • The product owner should open the meeting by quickly running through the agenda, highlighting the business value for features
  • They should encourage the audence to ask questions and feedback during the demos
  • Finally they should introduce the first demo
  • This introduction shouldn’t take longer than 1 minute

Demos

  • It is important to show real software because this will engage the audence the most. Powerpoint presentations / screenshots of functionality won’t engage the stateholders as much
  • Encourage developers to show the features they have coded. The developers will have worked hard to make the features and as a result, hopefully, some passion for the feature will come through in the demo
  • Often team members doing the demos are doing it on someone elses laptop. So, if they usually use a mouse, enourage them to bring their own mouse – it can be painful watching someone try to use a tracker pad on a laptop they have never used before
  • Allow / encourage team members to remote desktop on to their own box to do the demo. This reduces the risk of something going wrong because the demo laptop is not setup correctly. Ask the team member to make sure that remote desktop access is enabled on their box though!

Capturing feedback

Getting feedback is the most important part of the meeting – it what the sprint review is all about.

  • Make sure someone in the team (probably the product owner) collates the feedback
  • Be positive about feedback – this is what the meeting is about. If the feedback is negative and the team don’t necessarily agree with the comments then at least say that the team will have a think about it and perhaps suggest a separate meeting with the stakeholder to drill into the feedback further
  • Encourage feedback if there is silence after a demo … “what do people think?”. Pick a person out that you know is interested in the feature .. “any thoughts Bob?”. Very often people don’t feedback if the feature is spot on, so, we need to encourage people to speak up so that the team gets that validation

Closing the meeting

  • Encourage offline feedback. Stakeholders may well think of feedback after the meeting or maybe didn’t want to give negative feedback in front of a room full of people
  • Every so often, if there’s time, it’s worth asking the audience if they find the sprint review valuable and if there is anything they would like to change
  • Finally, thank everyone for attending and make sure they know that their feedback is really useful

After the meeting

  • Email the feedback back to the stakeholders after the meeting. This shows the stakeholders that we did listen and capture feedback. It also gives us a chance to make sure we have captured the feedback correctly – we may get more feedback, which is good
  • Make sure any changes and bugs are logged on the backlog

What about you? What do you find works well in sprint reviews?

Connect with me:RSSGitHubTwitterLinkedIn