Working in an agile team the days before a sprint demo is an intense experience. Everyone is extra focused. Test cases are run to find bugs. The last loose ends are tied up to make sure the entire sprint is finished. To me, a sprint demo is not only a way to show the progress of the project to the stakeholders, it is also a major success factor of the project itself.

When a project is first started a plan is made (this is an agile project, but there should still be a  plan). There are five major feature areas that are to be developed in parallel. The team starts happily developing, writing code in an exploratory way while learning the business domain and the technologies involved in the solution.

After a week, work has been started on four of the areas. So far everything is looking great. One of the features is obviously easier to implement that the others, but work has at least commenced on four of the five areas.

Things Going Wrong

Unfortunately things rarely just continue to work unless they get some attention. The finish of the project is often too far away to directly relate to the work being done in the beginning. Without a short term goal that’s within reach, the project easily drifts off. One feature is pushed through all the way. In itself that’s great, but not when another feature area is completely abandoned. One area shows too little progress and two are heading off in the wrong direction. One of them is even interfering with another area, but since no work is started on that area the conflict goes unnoticed.

At this point, problems are starting to build up, but they are still manageable. This is where the sprint goals can save the day, so let’s first have a look at what could happen without short term sprint goals.

Third Week without Sprint Goals

Now things really start get out of hand. One area is dragging off far away from the track. A lot of effort is obviously put into that area, but in the wrong direction. When the problem is discovered, all that work will have to go down the drain. That’s valuable project time lost without producing any value.

At this stage the project has a high risk of failure and a lot of time and effort will have to be put into saving it. The possibilities to keep the deadline are microscopic, even if a major budget overdraw is accepted.

What is even more scary is that there probably is no awareness in the team yet that they are heading off in the wrong direction. There are no intermediate check points between start and finish that help the team to ensure that they are on the right track. If you think this is a totally made up scenario, I’m sorry to inform you that things like this happens in the wild.

A few years ago, I was called into a 6 month project that was 5 months done – only to discover that they had spent the last 4 months running in the wrong direction producing absolutely no value. Intermediate check points would have made the problems obvious in time. Now the project had to be restarted, with 4 months of work going down the drain.

Introducing Sprint Goals

In scrum, the intermediate check points are the sprint goals. They help the team to find out in time when they are working on the wrong things or in the wrong direction. There will still be mistakes (the red arrows), but they will be caught in time and pushed back on track in time.

As humans, we tend to try to push away any problems and instead continue where we feel that there is progress. Sprint goals will help us identify areas that we’ve forgot or that’s heading off in the wrong direction.

In this example, the last area had not been started until the upcoming sprint demo forced the team to check the sprint goals. When looking closer, the team  found the hidden impediment that had caused everyone to focus on other areas instead.

Without the sprint goals, there is a high risk that the easy 80% of the system are developed first. Everything looks splendid – 20% of the time left and 20% of the development left. Except that those 20% are the hard 20% that will take 80% of the time… Intermediate sprint goals and sprint demos that forces the team to focus on the goals will make sure that those hard 20% are spread evenly over the project, reducing overall risk.

Sprint Demos are not Only for Stakeholders

The sprint demos are important to show the progress of the project to the stakeholders, but that’s only part of their value. The focus they bring to the development team are equally  important. That means that you should have sprint demos even if the stakeholders are not interested. You should do sprint demos for your intermediate goals even if you are not working agile. They will help you stay focused on the right things, find and handle impediments in time and increase the project’s chance to succeed.