INSTALLMENTS

Getting Started with Product Delivery

“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.

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.

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.”

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.

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.

GO MAKE A HULLABALOO!!!

Related posts:

I have spent a lot of time with you and i realized one thing. I always being grateful. Either you are the thing that I should be grateful for or anything. All the little things you did for me are…

This article has been migrated to Hashnode, please go ahead and read the updated version of the Graphical Introduction to the Intersection Observer API. The Intersection Observer is a Web API that…

When I started out in web development, I have started like most folks — naming css in the way it made the most sense for me. Because of this I would run into problems like having to think of the name…