There is a popular notion is some circles of Scrum, that Sprints need to produce shippable software at the end of every Sprint. This of course depends as always on the domain.
- Building a UI for the warehouse inventory control system for a rubber shoe company? This might be the case.
- Building software for a ground control system of a multi-billion dollar defense satellite flight management system? probably not.
- Building the health case enrollment system for a major western state? Possibly, but closer examination has to take place, before accepting the platitude that sprints need to produce shippable software every time they complete.
How about ...
- Architecture sprints - we're integrating with legacy production code that can't come down jsut because we didn't understand how the backend server farm works.
- Resources and facilities planning sprints - I worked a program a few years back that needed an actual aircraft carrier, Yep a fully functional air craft carrier was needed for several months, prepared in very specific ways, with very specific people on board. All the while all the software was bing build using iterative and incremental emerging requirements processes. They didn't call it Scrum, but ut was Scrum none the less
- Security sprints - Drupal runs alone for a multimillion line system will take a week. only to find gaps in the code security model
- Performance assessment sprints - those pesky Service Level Agreements
- How about the planning sprint - on large enterprise systems there are many interdependencies that must be addressed
- Independent Verification and Validation sprints - involves V&V work done by a third party organization not involved in the development of the product.
- External certification review sprints - DO-178C is one of my favorites. No software is going to be usable until it passes DO-178C. Same for NQA-1 on the nuke side.
So yes, Sprints MUST produce tangible measurable outcomes that can be verified to be compliant with the needs of the customer and other stockholders,m including external stockholders, but
...but your governance framework should not stop you from building a potentially shippable product increment each sprint
needs a VERY broad definition of Potentially Shippable Product, a specific domain and the governance framework for that domain. Only then can that notion have any chance of being a useful process goal.
And of course all this planning, executing, testing, V&V, performance assessment, etc. etc. etc. needs to have estimates for the probability of arriving on planned completion date, at the planned cost, and the needed capabilities fully functioning as required in exchange for the money being paid for the resulting value.
