I'm sometimes suppsed to demo work and I wonder if the Scrum methods have specified something about how demos should be done? I've done quick demos and I've been asked to demo on-the fly while it's not realistic to expect that programming always moves only forward. SO I'd like to know if you can tell me since I follow Scrum, if there is anything there that can improve my technical demos? For instance how often and when a demo should be done?

  • 1
    You say you're following Scrum but don't do demos? That is kind of strange because a sprint review is one of the basic practices of Scrum. Dec 19, 2013 at 22:41
  • @DaveHillier The review and demo aren't the same thing. The review is an internal team-examines-productivity-of-the-sprint, the demo is an external stakeholders-see-if-they-see-what-they-want. The review should always be there, but IMO the demo isn't really necessary if there's regular informal demos going on throughout the sprint.
    – Izkata
    Dec 20, 2013 at 1:54
  • 1
    "The review is an internal team-examines-productivity-of-the-sprint": Sounds a bit like micromanagement: I want to know what the team is doing on a weekly basis.
    – Giorgio
    Dec 20, 2013 at 7:42
  • Sprint reviews are supposed to be informal and previously I've allowed other stake holders to come along when they want to. Otherwise Scrum doesn't say anything about demos. Dec 20, 2013 at 10:33

1 Answer 1


Since you're using Agile, you're expected to have a working version at regular intervals. The intervals depend on your precise approach: it can be as long as a few weeks (the duration of your sprints), or as short as a few minutes if you use continuous integration.

Having constantly a working version makes it easy for your stakeholders to test themselves the product. In the same way, it's easy to make a demo to your stakeholders if they want to.

The fact that the project doesn't always move forward doesn't change anything: the demo is done on a working product in a given amount of time, not on the progress. If your stakeholders want to see the progress, in order, for example, to have a clear idea about what was done since the last sprint, they shouldn't ask for a demo, but rather go and see the backlog.

It's usually better to do the demos not at the regular intervals, but when you release a major feature. Indeed, making a demo after you spend two weeks doing major refactoring will give a bad impression on the stakeholders, which may reflect in their attitude towards refactoring, Agile methods, your team, your credibility, etc.

Remember that Agile encourages nearly-constant interaction between the team and the stakeholders, especially to quickly obtain feedback about what's just done and what is expected to be done soon. If this interaction is correctly done, stakeholders are already informed well about the current state of the product, the features and the progress. This makes demos much less useful compared to Waterfall projects, where the customer may remain blind during development, and discovers the project months later.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.