We can't release until the end of the sprint...

As I work with Scrum Team's, I find a common thread in teams that believe our releases are "tied" to the Sprint time-box. This is not the case. Releases are independent of the Sprint time-box. If you have something that meets the team's definition of done, the Product Owner has reviewed/accepted the functionality, and the team has the engineering skills to release frequently, RELEASE!

Origins

When Scrum first was being developed in the late 1980's and early 1990's, the most common length of the time-box was 30 days (1 month). It was typical then to release at the end of the Sprint. My theory on this is that the development tools we had back then might have precluded a team's ability to fully release frequently throughout the Sprint. The idea was that the team would work together in a cross-functional style to deliver the intended Sprint Goal and upon completion of the Sprint, they would release. 

Modern Times

I also believe that agile / empirical processes gained footing in the early 1990's because IDE/Development Tools fostered a more rapid delivery process. No longer were we taking punch cards in the hundreds to a shared CPU to schedule our job, run it, find out it failed, and do it all over again. Tools have drastically changed even from 2004 when I first began developing. Today, I find more and more teams rapidly develop features in a sprint; 1-3 days into the Sprint that meet definition of done in the target environment (which might not always be Production). As long as the Product Owner reviews the feature and accepts it as meeting the need, my opinion is that can be released any time during the Sprint. It has to touch all the "bases" but we don't have to necessarily wait until the Sprint Review. 

Do We Still Have the Review?

I still firmly believe in the final Sprint Review at the end of the Sprint to keep the cadence and allow Stakeholders/Customers/Product Owner/Team to collaborate on what we might work on next based on the feedback from the increment delivered. After-all, the outcome of a Sprint Review can be a completely revised Product Backlog. Even if the Product Owner has signed-off and released the features, I feel it is still a good practice to review the Sprint (remember the Sprint Review is more than just a Demo). It might go a lot quicker if the customers have already been using the features in Production. You can even ask if anyone wants to see the demo of the feature (if everyone has already seen it, then just gather feedback and input).

One day, Scrum might be revised to have the Sprint Review go the way of Product Backlog Refinement. It's an activity that needs to happen, but the Scrum Team determines the best times to have it. Let's not forget the stakeholders through the process though, so it's more than just about our team agreeing that we have built a done increment. It's about feedback and collaborating with the stakeholders as well. 


Related Articles

The Role of a Project Manager in Scrum

We had a great turnout at DFW Scrum last TUE for "The Role of the Project Manager in Scrum". Many organizations struggle with what to do with the Project Manager when they have a Scrum Team. Chris Eberhardt and myself facilitated this fascinating conversation. The reality is, there is not...

Read More

Core Scrum Roles

Just like the US Government has 3 branches (Judicial, Executive, and Legislative Branches), Scrum has 3 roles. Many people compare the counter-balance of each roles in Scrum to that of the US Government. It's really about the checks and balances. But I truly believe it is even more than that...

Read More

Stop Starting and Start Finishing

Ever run in a race or participated in a track meet? No matter how far the distance, when you cross the finish line, you’re done. It’s easy to understand and you don’t have to linger around, waiting for anything else to happen. What happens when you need to get an...

Read More

Is Your Team Focused with a Sprint Goal?

One of the 5 values of Scrum is Focus. Too often, I will ask Product Owners "What is the goal of this sprint"? Their response? "To get all of these Product Backlog Items done!" (and they look at me like...duh!)  My question is focused on ensuring that our Development Team...

Read More

Requirements in Scrum

Let's be honest. Most teams struggle with how to get requirements into their new "agile" process. Take Scrum for instance. Scrum says you start with what is called a Product Backlog. Let's see what the Scrum Guide says about the Product Backlog: The Product Backlog is an ordered list of...

Read More