We all know how it works – after a defined period of time (e.g. 3 weeks) you round up your stakeholders and Product Owner to demo all the great software you as a team have created. And what always happens the first time your stakeholders see “shippable” software? Absolutely correct – questions around functionality and design start to come up right in your demo. You’re asked “can we do this” or “change that”. The problem is that you’re only getting your first feedback loop at the end of your Sprint and in doing so you’ve almost guaranteed that delivering truly “shippable” software will extend into the next Sprint.
In order to have the best chance of delivering shippable software by the end of your Sprint, you need to get this software in front of your Product Owner and/or stakeholders multiple times throughout your Sprint. We call this continuous user integration where software is continually being tested and deployed to a development environment (for your PO to test) and a staging environment (for your stakeholders to test). The more feedback loops you can squeeze into your Sprint the better chance you’ll have of delivering software that is ready to ship when your Sprint ends. Keep in mind that utilizing continuous integration requires a greater emphasis on closing user stories than tasks and swarming is a great approach to make that happen.