It’s time for the next generation of Scrum: no Sprints needed. If you’re a small cross-functional team aiming to quickly deliver working value to your customer, pick the number one business and user need and build it. Get feedback, adjust, and release. Then pick the next one. Just deliver. Don’t throw in whatever a \[time box\] can fit. It’s not a container – it’s the lowest risk period of time teams try to manage. If you think the more tasks you throw in, the higher the chance to release – you won’t deliver anything.

# Waterfall

One can only understand Sprint Planning and time-boxed Sprints if one has worked in a pure waterfall project that lasted, let’s say, a year and a half before anything was released. What is released at the end of such a cycle is basically a new product, almost completely incompatible with the previous version.

\
The release notes are five pages long (that no one reads), and it takes another year to get existing customers accustomed to new versions. Most customers are unlikely to upgrade because the minor inconveniences a new release fixes isn’t worth the investment.

\
I remember one of the most impressive presentations about Agile Transformations. Large enterprise virtualization company. They used to release a new version once every two years. But the average time a customer used to get a new version with a change request of theirs in it was … wait for it .. four years. Because, just like enterprise vendors, enterprise customers are not agile.

\
It was impressive because they managed – the vendor – to transform and went all Scrum after months of training and experimentation. At the time of the presentation, they had teams that had started releasing directly to their customers every two weeks.

\
# Good Sprint

Four years versus two weeks – that’s the power of Scrum when done with the right intentions and the right way.

\
What is the right way? Decide and commit on all levels.

\
The risk mitigation superpowers of the time-boxed Sprints are based on simple mathematics and faith in destiny. You need to be a little superstitious to make it work.

\
Remember [Murphy’s law](https://hackernoon.com/why-would-anything-ever-go-right-7g1k36wy) – if anything can go wrong, it will go wrong.

\
Now, don’t get me wrong (unintended) – this is not about fear. This is about being reasonable. Information technologies are the fastest industry today. It’s one of the most complex ecosystems. There are tons of dependencies agile teams navigate through every day, most of them unplanned. You need [practices to help you be productive](https://hackernoon.com/why-continuous-integration-is-essential-in-agile-development) while dealing with the inevitable daily surprises.

\
There’s another famous law – a deficiency in any one of a number of factors dooms an endeavour to failure. Consequently, a successful endeavour (subject to this principle) is one for which every possible deficiency has been avoided.

\
And here’s the question – **for how long can you avoid every possible deficiency** to make sure your endeavour is going to be successful?

\
Can you make sure that all internal and external dependencies to your product and team – people, tools, resources, world economy —  will remain stable and in a condition favouring your goals for six months, one year, two years?

\
No, you can’t.

\
That’s why here comes Scrum with its safety net of time-boxed Sprints. One to three weeks sounds foreseeable, feasible, and low risk.

\
We might try to get all conditions in place to deliver high-value and high-quality to our customers within two weeks or less. Sounds achievable, right?

\
We have the time to consider the risks and continuously get feedback on customers’ top needs. The developers confirm they understand those top priorities and have everything they need to implement and deliver as expected.

\
The expectation is to work and to receive it sooner than four years.

\
Release early and release often. **Sprints enable [continuous delivery](https://hackernoon.com/a-comparison-of-agile-lean-and-continuous-delivery) to happen at all.** Once you master this, remove the Sprints and release earlier and more often – several times a day, for example.

\
Scrum and Sprint Planning are a good step toward limiting and avoiding the risks of delays, not delivering at all, rework and waste and throwing months of work in the bin because no customer will get it. What’s sadder – no customer might need it anymore at the time we release it already if there were no Sprints.

# Bad Sprint

The problems with Sprints begin when we start mixing Time and Space. And instead of perceiving “time-boxed” as a limit for time, we interpret it as a container for tasks and start throwing as many tasks in the “box” as it can fit and some more on top in case we finish some earlier. As if it has ever happened.

\
And this is when our Scrum fails.

\
Еngineers are not superstitious. They are opportunistic. They believe nothing can ever go wrong, and their plans are foolproof. They don’t believe in risk. That’s what lets them drive world innovation and technology but this approach has some downsides.

\
**The worst thing we can do in Sprint Planning is to initiate it with the question, “How many tasks can we fit in this Sprint?”**

\
This is the root cause of all evil we’re witnessing in Product and Engineering management nowadays.

\
It doesn’t matter how many tasks your team *thinks* they can do in one Sprint. What matters is which task they can get done that your customer can begin using at the end of the sprint.

\
If you don’t have a strong Product Goal turned into Useful, Meaningful, Feasible, Releasable *descriptions of users’ needs* that your team can commit to delivering *first* with *high quality*, and if you don’t have a clear vision and mechanisms how to handle the *unplanned deficiencies* that will inevitably occur during the Sprint, your Sprint Planning is useless and a waste of time.

\
**Throwing tens of items in that box doesn’t increase the chance to *at least release something*.**

\
On the contrary, it’s a sure way to failure and team demoralisation.

\
There are two scenarios for bad Sprints. The one above is the most common occurrence – trying to add as many work items in the Sprint as the *velocity* suggests. Have you noticed how we never plan as many stories as is the average velocity despite the Velocity charts? We always add more.

\
I cannot count how many times I’ve heard:

“Oh, we have *a capacity* for some more story points. Which tasks should we add?”

“Let’s leave some *capacity* for bug-fixing.”

“Nah, let’s *plan the whole* Sprint, and we can always *remove* the ones at the bottom if we see we can’t complete them at the *grooming* meeting.”

\
Guess how the Sprint ends. We *almost* manage to get a couple of tasks done, 18 stories are *moved* to the next Sprint, and 6 are moved back to the backlog.

\
That’s why it’s called a backlog – **it’s the log of everything we moved back.**

\
The other scenario of Sprint Planning failure is when the [product backlog is almost empty](https://hriskoleva.com/blog/youre-doing-scrum-wrong/). This is actually the best thing if it’s on purpose, but when it is because the product manager does everything except figuring out what the most important features, fixes, and improvements are, which we should do first in order to meet customer expectations, grow our business and advance with our technology, this is a symptom of a burned-out product manager, wasted team effort and motivation, and irritated stakeholders. This is when the product manager gets fired.

# The Next Generation Scrum

We need new Scrum terminology for the 2025 edition to get people to get it. Let’s try to reimagine the next generation of Scrum:

\
* Timebox becomes **Low-Risk High-Efficiency – Streamlined**. *E.g., The daily meetings are streamlined.*
* The Sprint becomes good old **Iteration** because, with Sprints, we forget to *iterate –* build and get feedback and then build and get feedback again until the user is happy and we’ve reached our goals. *E.g., What customer value are we going to deliver this iteration?*

  \

Rather than sprinting (literally being in a rush because it’s a huge story) and coding for five Sprints and eventually caring to get feedback. That’s not agile.

\
* The Product Backlog should be straightened to **Priorities** because apparently, repeating a thousand times that the Product Backlog should be ordered by priorities is not enough. That’s why we should start talking only about Product (Business, Customer) Priorities. It implies thinking about what’s most essential and game-changing for the business compared to a To-Do list with random notes. *E.g., Which are our top priorities as a company?*

# No Sprints. Just deliver.

Now, we clarified that all that matters is the company’s strategic goals, the business development plans, the customer needs, the technology evolution, and the product vision – *the Priorities –* we have to just start working on them.

\
Which one to choose? Which one is the top priority? I like the idea of the one that will make the most significant difference – in quality and quantity.

\
The one that will enable the **highest growth**. The one that will open the largest market expansion. The one that will bring more customers. In terms of quality, it’s called **Functional Suitability** (appropriateness, completeness, correctness).

\
The one that will **retain all customers** and increase your product **Reliability** (maturity, availability, fault tolerance, recoverability) and Performance Efficiency. If your system had a significant downtime last month, then you need to invest in your infrastructure – also Reliability.

\
The one that will offload customer success teams so they can really focus on success *instead of support. The quality characteristic to make this happen is **Usability** (learnability, operability, user error protection)*.

\
The one that will make the product **Maintainability** (modularity, reusability, analysability, modifiability, testability) more efficient. That’s the one that will **reduce the cost** of bug-fixing, lower the regression risk, and **speed up the releases** by enabling continuous delivery.

\
It might be that the last big feature was heavily delayed because of unforeseen regression issues. Then the one you should probably prioritise is cleaning tech debt and heavy refactoring. It will again increase your maintainability.

\
There will be a few items in that priority list that are equally important. The prioritisation strategies differ depending on your business context at the moment. It might be that a big fish customer is knocking on your door. Then you’d go with the new big feature they are waiting for. This is the **Functional Appropriateness** of your product. And the entire Team should start working on it together.

\
**Whatever your current product situation is, account for it and always lean on the one that increases the quality of your product and service. It’s always the right choice.**

\
Once you decide what your goals are, it gets easy. [Gather the entire team together and let them create](https://hriskoleva.com/blog/best-quality-assurance-tools-for-agile-teams/). Let them think and ideate, let them draw and scratch, let them get loud, let them play, let them build features they are proud of, you are proud of, and your customers are recommending. Let them deliver your five-stars product to your thousands of happy customers.

\
You don’t need Sprints to do that. You need a clear vision and Priorities.

\
Decide. Commit. Succeed.

\

:::info
Also published [here](https://hriskoleva.com/blog/the-next-generation-scrum-no-sprints/).

:::

\


Too Long; Didn't Read

Cassandra Forward a free Cassandra-focused community event

The Next Generation of Scrum: No Sprints Needed. Just Deliver

Too Long; Didn't Read

@hriskoleva

RELATED STORIES