3 minute read
Are you able to see working software that could be shipped to production if the Product Owner chose at the Sprint Review? Do you review that done increment and update the Product Backlog in the Sprint Review?
If you don’t then your team is probably not doing Scrum!
Scrum is designed to implement an empirical process control system, and such a system can only be built on Trust and Courage. Only with Trust and Courage can you get Transparency and only with Transparency can you inspect and adapt. Without inspect and adapt you are not empirical, and thus are not doing Scrum.
The working increment provides us with transparency of the past
Being able to see what was done is paramount to not only building trust, but seeing what value was delivered. This affords us the opportunity to inspect and adapt what we do next based on what we see in the product now.
What if we don’t have transparency of the past?
If you don’t have transparency of past then how do we know what was done? If it’s only half done, or 90% there, then its just not done, can’t be shipped and we loose transparently of the past. 😥 There should be no further required by the development team to ship your product to production.
Unfortunately having working software at the end of the Sprint is not very common in the industry. If we don’t have working software how do we know what was done? How do we know what we are looking at in the Sprint review.
Who is accountable for that working increment?
Scrum places the accountability of working software clearly and explicitly at the feet of the Development Team. That places quality decisions in the Development Teams hands, and the choice should always be for higher quality. Make sure that you have a definition of done, and then work to have it mirror releasable.
Subscribe to Martin's articles
Writing since 2006
Articles, usually weekly on Mondays. One click to leave.
Who can choose to cut quality?
It is ok to cut quality as long as it is a C-level decision. Cutting quality on software that you build for customers, and cutting quality on software you sell, is fraud. All software built exists as an asset on someone’s balance sheet, and misrepresenting the value of an asset in your company accounts is not a good idea.
Let’s all work together and enable high quality working software at the end of every Sprint!
Enjoyed this? One click, no account.
Questions this answers
What role does the working Increment play in providing transparency in Scrum?
The working Increment shows exactly what was done and what value was delivered in the Sprint, making the past transparent so stakeholders can inspect the product and adapt what to do next based on what truly exists now. Without a releasable, done Increment at the Sprint Review, the team loses transparency of the past and cannot effectively inspect and adapt.
Who is accountable for the working Increment in Scrum?
In Scrum, the Development Team is explicitly accountable for creating working, releasable software each Sprint. Quality decisions sit with the Development Team, which should define and follow a Definition of Done that closely mirrors releasable quality.
Who is allowed to decide to cut software quality in Scrum?
Only C-level executives should make a decision to cut quality; it should not be a decision made within the Development Team alone. Cutting quality in software built for customers or sold as a product is considered fraud, because it misrepresents the value of the software asset on the company’s balance sheet.
Smart Classifications
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.