Its a review not a demonstration

At the end of a Sprint the team get together with the client to review the work that has taken place over the Sprint in a meeting called the Sprint Review.

On some of our projects this meeting has been under-utilised with the developers completing a demonstration of the system.

Why is this a problem?  Well, the demonstration is a scripted display of the work that has been completed.  The developers will, completely subconsciously, click on what they know works and keep to a minimum any time spent demonstrating things that don't work so well.

This means that the client walks away without fully understanding what has been delivered and therefore can't accurately specify what is required during the next Sprint.

Sprint Reviews should be interactive sessions.  The team should show each story in turn with the client asking questions and interacting, hands on, with the system.  This way both the client and the team can agree on what is really done and can together understand what the contents of the next Sprint may be.

Choosing the length of your sprint

Our development team generally work on projects with sprint lengths of 2 weeks.  However over the last few months we've been experimenting with different iteration lengths and on a recent project this was set to 1 week.


We decided on this length as, when we started development, the requirements for this project were in a state of flux and we felt that a shorter 1 week sprint would give us the most flexibility to deliver the changing priorities.

As the Product Owner continued to drastically change their priorities it became clear that the shorter sprint did allow us the flexibility we needed to continue to provide value to this particular client.  However there were a number of challenges that this created.  During a 1 week sprint our team found it hard to find a rhythm to their week, it was almost as if they were always trying to catch up in order to deliver their committed requirements.  This lack of rhythm was visible in the sprint burndown which didn't seem to find a flow, meaning that we couldn't use it to predict if we were on track to deliver or not. 

Also, there was a lot more overhead with twice as many planning and review meetings than we normally had, meaning that there was less time for delivering requirements.

These byproducts caused our team to tire quickly and we wouldn't have been able to keep up this pace for longer than 5 or 6 weeks.

Our team found that shorter sprints are possible, and sometime necessary, however the pace can be difficult to maintain for more than a few weeks.