A better way than staggered iterations for delivery

[giscus[bot]]

A better way than staggered iterations for delivery

Discover a superior approach to delivery that enhances agility and reduces technical debt. Learn how to implement effective cross-functional teams today!

https://nkdagility.com/resources/blog/a-better-way-than-staggered-iterations-for-delivery/

[astorDev]

Martin, but still to complete an iteration we need to integrate the work of all developers, right?

In the article you've proposed the following question:

Does QA sit around till the end of the iteration after the one they reported the problem in?

I would like to propose a reverse question for your ultimate scrum approach:

Does Backend Engineer sit around till the end of the iteration after completing the backend work?

And all the recommendations I see only minify the staggering, not remove it. So my hot take would be that we still need some staggering, just not as much as in your example. Here's how I see it:

Let's say we have a feature 1, which is going in iteration 1, and feature 2, which is going in iteration 2.

1. During iteration 1 BA starts to think about feature 2, giving specs in about the middle of the iteration 1
2. Backend developer finishes work on feature 1 about the middle of the iteration 1. Now he starts work on feature 2 (Since the developer start work earlier than iteration start the developer also completes work earlier). If something is needed to be fixed about feature 1 the developer switches to it almost immediately
3. For frontend developer it's similar for backend, but moved to 3/4 and 1/4 of the iteration accordingly
4. QA works till the end of the iteration and in the beginning of the iteration 2 reads specs and prepares test cases (which he will soon use to test the backend)

What do you think about that? And what's the real alternative

[MrHinsh]

Your proposed workflow isn’t unusual, but let’s unpack why it doesn’t align with Scrum's essence and explore alternatives.

1. The Problem with Staggering Work
The staggered approach assumes sequential handoffs, creating dependencies that slow feedback and increase risk. For example:

• If the backend developer works on feature 2 during iteration 1, how can we truly deliver a "Done" increment of feature 1 by the end of iteration 1? Without integration and testing, feature 1 is incomplete.
• QA is left to "clean up" at the end, which delays feedback to developers and perpetuates the waterfall mindset.

In Scrum, Done means Done—fully integrated, tested, and potentially shippable.

2. A Better Alternative: Fully Cross-Functional Teams
Instead of staggering work, Scrum teams should aim for concurrent collaboration:

• Developers (backend, frontend) and QA work together on feature 1 throughout iteration 1.
• As soon as a backend module is ready, it’s integrated and tested alongside the frontend.
• Testing is continuous, not deferred to the end.

This approach eliminates the "idle time" you’re concerned about because everyone is actively involved in delivering the same Sprint Goal.

3. Refocusing on Value, Not Utilisation
The key is to shift focus from 100% individual utilisation to maximising value delivery. The question isn’t, “What can the backend developer do after their piece is done?” but rather, “What can the team do together to finish feature 1 faster and better?”.

4. What About Refinement and Planning?
Yes, refinement is ongoing, but it doesn’t mean developers should prematurely start work on the next Sprint’s items. Instead:

• Refinement can involve everyone clarifying and breaking down future work.
• Developers can contribute to improving test coverage, automation, or even helping peers complete their work.

The True Alternative

• Work together on one increment at a time. Backend, frontend, and QA should integrate their work continuously.
• Use tools like CI/CD pipelines to automate integration and testing.
• Treat the Sprint as a unit of delivery, not a relay race.

Your proposed staggered approach might feel efficient, but it undermines the core Scrum principles of collaboration, quick feedback, and delivering truly "Done" increments. Let’s aim for flow, not juggling multiple partially complete items.