Benefits and Drawbacks of Interim Sprint Demos
One of the great aspects of scrum/agile is the ability to quickly produce small but tangible results to your client. The way these results are usually shown is through demonstrations of functionality at the conclusion of development sprints. But what about doing more frequent demonstrations? Would the project benefit from interim, ad-hoc demonstrations at the customer’s behest? Or is it in fact more harmful to the project. This post will dive into some of the points for and against more frequent product demonstrations.
Pro: More Client Input Early On
Client feedback is always great to have early on. Remember, the golden rule of change is that the earlier on it’s implemented, the cheaper it is. Plus it’s a reassuring feeling to know that what you’re building for the client is hitting the bullseye as you continue to build on top of it. You can continue to build your client’s trust in you which does afford you the ability to take more calculated risks that could potentially benefit your project.
Con: More Time Spent Preparing
As with any demonstration, as much as the client can say they will accept ad-hoc and know there will be errors, the entire point of a demonstration is to prove something is working. To that end, time needs to be dedicated to ensuring that the demonstration goes smooth. While more infrequent, ad-hoc demonstrations may not need the full prep time that a more comprehensive demonstration would take, it still requires time to be spent either by your developer or business analyst to ensure that what you’re showing the customer is going to make it worth the time spending doing the demonstration. Not to mention it also requires the development to cease for a period of time to offer a stable environment to demonstrate out of. Often times these costs (both schedule and budget) are not accounted for and can quickly add up over time.
Pro: Minimal Surprises at Sprint’s End
As with the whole point of agile/scrum, the expressed purpose of frequent show-and-tells to the client is to minimize surprises at the end of the project or sprint. While sprints are not usually a long period of time (1-3 weeks usually), sometimes that amount of time can be costly to a very tightly scheduled project. By having more frequent demonstrations during the development of sprint functionality and sharing that with your client, there is a much smaller chance of a surprise at the end of the sprint that would result in rework.
Con: Potential to Invite Change (Scope Creep)
As with any demonstration there is always a chance that scope can change as a result of a client seeing something “in the flesh” that the envisioned would be different when it was in the requirements stage. This can present the potential for inviting scope creep to your project (which you as a project manager should expect and be prepared for). What can be a negative though is the constant defending of scope, especially if your contract is loosely worded. This can lead to countless meetings and discussions around why something should be considered in or out of scope.
In the end, the goal of your project is to have a happy customer with a usable product. How you get there can be a number of ways and methods. Every customer is different, every project is different. Having a regular cadence of demonstrations is a must but infrequent, ad-hoc demos can be sometimes advantageous if managed properly but can also lead to some unforeseen challenges.