Why do so many Scrum Teams “carry over” work from Sprint to Sprint?


There’s no such thing as “carry over” in the Scrum framework. In fact, there are many mechanisms in place ensuring that work gets done and daily transparency into it not getting done.

One thing you might want to watch- using software tools to store the Sprint Backlog can contribute to work becoming hidden, or dark. It’s easy to just “add a card” or increase a Task time instead of unhiding that additional work.

What’s intended at Sprint Planning is the break down or decomposition of items pulled from the Product Backlog that the Development Team believes can be completed (that can get to done) during the Sprint. This is called “Topic One” in Sprint Planning or “What can be done this Sprint”?

What’s intended to happen next is often forgotten or lost. “Topic Two” or “How will the chosen work get done?” involves the Development Team breaking those Product Backlog Items down even further. Decomposing them into units of one day or less.

Why units of One Day or Less?

Scrum is an empirical process. That’s a fancy way of saying we course correct based on what we are learn. It requires Transparency to Inspect and Adapt appropriately based on what we uncovered or learned. The Daily Scrum is a Transparency, Inspect and Adapt mechanism on the Sprint Goal.

This is not intended to be a micro-management technique- just the opposite! Breaking work down enables Development Team members the chance to show progress towards the goal. That’s far more satisfying and motivating than staring at the same big blob of work on a backlog every day.

 If work is not broken down to units of One Day or less, no visibility is provided at the Daily Scrum. This is the land of 75% Done and Status Report Syndrome.

Why is lack of visibility or transparency so important?

The Daily Scrum provides an opportunity to Inspect and Adapt if the Sprint Goal is not met.

It’s also a Daily opportunity to provide visibility into where I’m stuck, where I didn’t get work to done and what’s getting in my way. Once the rest of the team knows this they can offer to help. It provides a way for the work to get “unstuck” and get Done – achieving the Sprint Goal. That’s far more enjoyable than listening to someone say over and over again “I’m still working on that thing, no blockers”.

Without this daily transparency, the Development Team and the PO have no idea if the Sprint Goal will be met until maybe the very end with no chance to course correct. We’ve also lost a learning opportunity and an opportunity for the team to pull together, working with each other to achieve their common goal.

Our Own Experience with Uncovering Dark Work

CoLeadTeam doesn’t just offer services using Agile and Scrum, we use the same framework we teach to manage our own work in two-week Sprints. Now you might be thinking because we teach this Scrum stuff, we’re really good at it right?  Nope!  The empirical nature of the process exposes what’s not working and CoLeadTeam is not immune to this. We found ourselves falling into the Dark Work trap many of our students and clients experience.

We noticed that the same thing being said at Daily Scrum. That items on our Sprint Backlog were piling up in Work in Progress (WIP) and very little was moving to Done.

We also noticed that team members weren’t offering to work together to get items to done, they would pull new items from the Sprint Backlog Not Started column into WIP.

Yep! We found ourselves in the same murky carry over situation that we caution our students and clients against. Dark Work!

At a Sprint Retrospective we agreed it was time to do something about it. A team member took one of the items on our next Sprint Backlog and brainstormed with other team members all the things that really needed to happen in order for that one item to be truly done.  The result?  There were over 30 units of work that needed to be done!


All hiding under just one card, one item on our Sprint Backlog. 

Shining a Light on Dark Work – What Can You Do?

·       Recommit to Topic Two of Sprint Planning:  Break work pulled into the Sprint down into units of one day or less.

·       Recommit to the Sprint Backlog: this artifact is the way the Development Team manages their work during the Sprint. It provides visibility into where items are on a daily basis and at a glance shows whether the Sprint Goal is on track…or not.

·       Recommit to Daily Transparency: the Daily Scrum isn’t “here’s what I did yesterday” it’s “here’s what I got to done towards the Sprint Goal”. Get on track with the actual suggested questions to be answered as noted in the Scrum Guide (https://scrumguides.org/).

·       Recommit to Transparency, Inspection and Adaptation: if there’s work not done, who can help? What is needed to get it done?

·       Recommit to the Sprint Retrospective: the Scrum Team (Product Owner, Scrum Master and Development Team) identifies a process improvement to correct in the next Sprint. If you still have carry-over from Sprint to Sprint, you have not effectively resolved the root cause of your process impediment. What is needed to prevent carry-over and uncover Dark Work?

If you’d like to learn more about using Scrum more effectively in your organization, join us for an upcoming course or event.