The Sprint is a container for Planning and not necessarily for Delivery



I have been told time and again in the office that Scrum is an inflexible platform for developing software as it is way too prescriptive. This is far from reality and represents an invalid interpretation in the rules of the game. This fault lies not with those that have been turned away from the light, but with the fanatics that have brandished the burning torch and pitchfork at your door chanting “that is not Scrum because…”.

Figure: Please ignore these guys

Many of us in the community have a vision of making Scrum more accessible to all and to that end, one of the goals of the entire Scrum community should be to help the misguided back to the light and re-educate the Scrum Coaches ( read Inquisitors here ) that have corrupted them.

Let me ask you a question;

If the Scrum Guide is the rules by which the game of Scrum is played, then where is it written that your delivery schedule must match up with your planning schedule?

It does say that you should be meeting your definition of done for each PBI and at least each Sprint. As your definition of done is the quality bar set by the Development Team and negotiated with the Product Owner, what is to stop you having the following DoD:

  • Acceptance Tests have been turned into Test Cases

  • Functional Tests have been turned into Test Cases

  • Code coverage percentage is the same or better than the last build

  • All Tests Cases pass

  • All Test Cases have been turned into Coded UI Tests

  • Deployed to QA and full automated test suit run

  • Deployed to Production

If you are deploying to production every Sprint and even for every PBI then you are one step away from doing it for every build, which is Continuous Deployment. Does Scrum say that you can’t do this? Hell no, it encourages it without mandating it. As long as you meet a simple measurable checklist, you can say that you are doing Scrum.

“Businesses rely on getting valuable new software into the hands of users as fast as possible, while making sure that they keep their production environments stable. Continuous Delivery is a revolutionary and scalable agile methodology that enables any team, including teams within enterprise IT organizations, to achieve rapid, reliable releases through better collaboration between developers, testers, DBAs and operations, and automation of the build, deploy, test and release process.”
-Jez Humble

Even if you are not practicing Continuous Delivery, I would encourage you to deploy more regularly than just once a Sprint. I am not saying that it is easy, because it is not.

You can’t do this with immature software either. I see customers fail time and again with institutional technical debt and software teams that are highly tuned to create it. In order to achieve Continuous Delivery your organisation must be committed to minimizing technical debt and to maximizing the value delivered to your business. Apart from technical debt there are a quandary of things that need to be in place in order to achieve Continuous Delivery. Think about the ability to have different versions of the same code running in production at the same time while maintaining the contracts and separation of concerns that go to make that possible.

There are only a few organisations that have mastered Continuous Delivery, but the benefit that they achieve in being able to get features into production almost as fast as the business can think of it.

But if you do want to get there, or at least take a journey down that road and see how far you want to go then there are things that must happen. There are waypoints along the road and provide a simple guide to your maturity in this area:

  • Automated Build

  • Build Verification Tests

  • Automated Acceptance Tests

  • Automated Functional Tests

  • Automated Unit Tests

  • Automated Deployment

Only once you have all of these thing should you then be thinking of what more do you need for your software in your environment to be able to successfully deploy your software to production and be happy that you have met the correct quality level to achieve this.

I never tell teams that you MUST do a thing but instead encourage them to do the right thing for their organisation in a journey to build better software.

Now, that is something that we can all aspire to.

Upcoming Training Opportunities

These are the next five classes we have, and you can check out our full public schedule of classes.

Live Virtual Advanced Professional Scrum Product Owner Online on 6th February 2022
Virtual Advanced 0
6-9 Feb, 2023
09:00-13:00 EST
Live Virtual Professional Scrum Product Owner online 13th February 2023
Virtual Intermediate 0
13-16 Feb, 2023
09:30-13:30 GMT
Live Virtual Professional Scrum Master Online on 20th February 2023
Virtual Intermediate 0
20-23 Feb, 2023
09:00-13:00 EST
Live Virtual Applying Professional Scrum in Minecraft on 27th February 2023
Virtual Beginner 0
27 Feb-2 Feb, 2023
09:00-13:00 EST

We can deliver any of our courses as private in-house training over Microsoft Teams & Mural. We also recommend training based on your accountabilities or role, you can go directly to recommended courses for Scrum MastersProduct OwnersDevelopers and Agile Leaders.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Related Courses

No items found

Read more

Martin Hinshelwood (He/Him) How does the APS course help people apply scrum effectively? The APS (Applying Professional Scrum) course helps people apply scrum effectively in a number of ways. A practical encounter with Scrum. The APS course is incredibly practical and hands-on by design. So, during the course, people develop a deep …
Martin Hinshelwood (He/Him) In what circumstances is agile consulting appropriate? Agile consulting is almost always my first and favourite approach when working with customers. Internal Core Competencies The only reason why an organization thinks that they need an agile coach, rather than an agile consultant, is because of a systemic lack of …
Martin Hinshelwood (He/Him) How is agile product development different to waterfall project management? Defining the difference between agile product development and waterfall project management is actually a very difficult task because most agile teams that I encounter are agile but under a waterfall project management environment. Defining waterfall project management. To understand …
Martin Hinshelwood (He/Him) Why does Minecraft make the APS course so awesome? I started teaching the APS (Applying Professional Scrum) course with Minecraft about twelve (12) years ago. The context for complexity in a classroom. Before Minecraft, I used to use an animal website as a case study for the course. We’d …


We believe that every company deserves high quality software delivered on a regular cadence that meets its customers needs. Our goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals.

naked Agility Limited is a professional company that offers training, coaching, mentoring, and facilitation to help people and teams evolve, integrate, and continuously improve.

We recognise the positive impact that a happy AND motivated workforce, that has purpose, has on client experience. We help change mindsets towards a people-first culture where everyone encourages others to learn and grow. The resulting divergent thinking leads to many different ideas and opportunities for the success of the organisation.