Getting Started with Product Delivery
The Sprint Review & The Increment (Part 9 of 10)
“Have enough courage to start and enough heart to finish.” - Jessica N. S. Yourko
The Sprint Review is the event where the Scrum Team and the Stakeholders come together to inspect the outcome of the Sprint (aka the Increment that meets the Definition of Done), they collaborate on what to do next, and possibly adjust the Product Backlog to meet new opportunities. There’s a lot packed in that previous sentence and we’ll be diving into three parts of it; the Definition of Done, the Increment, and the Sprint Review.
Definition of Done
How do you know when you are done? That is where the Definition of Done comes in. Prior to your first Sprint, the Scrum Team should create a Definition of Done (DoD) that is in writing. Seriously, if it is not in writing, then you do not have a DoD. You may have a vague idea in the heads of a few members of the Scrum Team, but you do not have a real DoD.
The DoD is one of the three commitments in Scrum and it provides transparency and focus to the Increment. It does this by stating the required and measurable quality standard for the Increment. Every Item of work must meet the DoD in order to be considered part of the Increment.
The Scrum Team works together to define and document a DoD. You start with the organization to see if there is a standard already set at that level. If there is, then you already have the start of a DoD. The next question that the Scrum Team needs to ask is, “Is there anything else that is needed in order to deliver a working Increment to our customers?” If there is, then the Scrum Team needs to add those things to the DoD. Done means “no more work is needed in order to ship it to your customer.” Done = Releasable.
The DoD is a commitment that the entire Scrum Team creates together. This is important because everyone on the Scrum Team should care about and contribute to the quality of the Product and it also helps with providing a shared purpose for the team.
- Developers: For the Developers, the DoD helps them with determining how much work they can potentially take on for the current Sprint. It lets the Developers know when they can and should stop working on an item. It is also the Developers’ responsibility to make sure that the Items in a Sprint conform to the DoD.
- Product Owner: The Product Owner cares about the DoD because it can affect the product’s total cost of ownership. It also allows the Product Owner to assume a certain quality level of the Increment at the end of each Sprint.
- Scrum Master: The Scrum Masters helps with facilitating improvements to the DoD as part of their accountability for the Scrum Team’s effectiveness. They can also leverage their coaching skills to help challenge assumptions and support the Scrum Team in trying new things in the pursuit of continuous improvement.
Please don’t confuse the DoD with the Acceptance Criteria. The Acceptance Criteria is a set of conditions a specific Item has to fulfill in order to be shipped. It applies to one and only one Item. The DoD on the other hand applies to ALL Items. To this point, you often see in a Scrum Team’s Definition of Done a statement that says something like, “The Item must fulfill all Acceptance Criteria.”
Sample Definition of Done:
• Available on _______ landscape. (What environment?)
• The code is well-written. That is, the team does not feel they need to immediately refactor or rewrite it.
• Peer Review has been performed
• The code is checked in
• The code comes with automated tests at all appropriate levels.
• The code has been either pair programmed or has been code inspected.
• The feature the code implements has been documented as needed in any end-user documentation.
• Required Documentation Completed
• Acceptance Criteria Met
• Performance Testing Completed
• Knowledge Transfer Completed
• Security Testing Completed
• Non-Functional Requirements Completed (FURPS+)
Increment
A lot of people go through Agile and Scrum training where they are exposed to the Agile Manifesto that says, “Working software is the primary measure of progress.” and the Scrum Guide quote that states, “The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint.” However, there are still a lot of so-called “Scrum Teams” that claim they are being Agile and doing Scrum while Sprint after Sprint they deliver nothing that is potentially usable or of value to their customers. This is not being Agile or doing Scrum and it is not the approach to take if you are planning to shift from Project Delivery to Product Delivery.
The definition of an Increment is an interesting one. An Increment is the integration of all the work that meets the Definition of Done during the current Sprint plus all prior Sprints. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. Simply put, the Increment is your working Product.
Sprint Review
The Sprint Review is an event where the Scrum Team and the Stakeholders inspect the working Product (aka the Increment) with the purpose of gaining feedback on the value that was delivered. Afterward, the participants collaborate on what to do next with the possibility of adjusting the Product Backlog to meet new opportunities. You can do a lot of things during the Sprint but by the time you get to the Sprint Review, there should be something, no matter how small, of value that is potentially shippable to the client. The Sprint Review happens near the end of the Sprint but just prior to the Sprint Retrospective. The maximum duration of this event for a one-month-long Sprint is 4 hours.
Please do not call the Sprint Review a Sprint Demo. Calling this event a Sprint Demo would be like saying you are going to a fight when in reality you are going to a hockey game. Fighting is a tactic in hockey, but it is not the only thing. The same is true with the Sprint Review. There is a demo that occurs in the Sprint Review but it is only a fraction of what needs to occur during this event. The main purpose of the Sprint Review is to collaborate and obtain feedback.
Other than the Sprint being canceled, there is no reason that the Sprint Review should not occur each and every Sprint (Ok, maybe if you don’t want to do Scrum anymore. Yeah, that’s a good reason to cancel the Sprint Review.) Many Scrum Teams skip the Sprint Review stating that the Increment is not yet in a reviewable state or that the Sprint Goal has not yet been met. Nowhere in the Scrum Guide does it state that these reasons, or any others, are prerequisites to having the Sprint Review. Some would argue that these excuses are even stronger reasons you need to have the Sprint Review. We inspect the Increment every Sprint no matter how challenging it may be to do so. This is the time for the Scrum Team to be transparent with the Stakeholders, discuss the challenges, and collaborate on what to do next.
INSTALLMENTS
- Introduction with Table of Contents
- Previous Installment: Getting Started with Product Delivery: The Daily Scrum (Part 8 of 10)
- Next Installment: Getting Started with Product Delivery: Sprint Retrospective (Part 10 of 10)
I am very interested to learn what you think about this topic. My LinkedIn profile is https://www.linkedin.com/in/phooey
GO MAKE A HULLABALOO!!!
