Why We Need to Stop Talking About “Carryover”

I think that the term carryover can be used, but during planning there should be a conversation about the work that is left. Always check if it needs to be 'carried over' or if it should go to the backlog. I know that officially the left over work should be placed on the backlog and prioritized. But if the work is important and needs to be finished, why go through all that administration?
If the work does not need to be carried over, we do not need to discuss in the planning any further. Prioritization can be done afterwards, saving a lot time during the meeting.

So for me, it is about having the conversation. Maybe giving it a name makes it easier to discuss it properly. But those are just my 2 cents

Thanks for sharing your take on this. I don't think we are too far apart in our approaches. And glad to hear (well, I guess I'm assuming from what you shared) that your team doesn't feel pressured into "carrying over" "carryover" just because they use that terminology.

I don't think updating items that were already refined in the Product Backlog should be a lot of administration. If it is, maybe have other challenges :-) I agree it can be a conversation, and if it does go back in the Product Backlog, it can be refined further and re-ordered at any time.

Totally agree with this article. In the first place we do not plan a sprint just to have carryovers in the end. Maybe it will help by having conversations around this area during planning. Are we expecting carryovers because we think we have more planned stories this sprint and we did not care to put a little buffer for any unforeseen circumstances? Do we want to keep on having carryovers sprint by sprint even if at some point we are no longer achieving our sprint goals? Do we see an opportunity for improvement here? .....These questions were just a few of them which the whole scrum team must try to have conversations around it.

Hi Stephanie,

1. In this example, how does the Sprint Backlog look at the end of the Sprint? Do you mean that all work is exactly finished at the end of the Sprint, because we all know that doesn't happen, and it would even be smelly if it did.

2. Let's assume that the Sprint Goal is achieved 3 days before the end of the Sprint, what now?

We generally refer this as 'Spillover' and since our PB is already ordered with one or two sprints of work during our refinement meetings, it is automatically pulled into next sprint backlog based on priority.
To correct, albeit, rather minimize, this Spillover, teams plan basis this spillover work plus how much more they can pick based on the average of their past 3 to 4 sprints velocity. Initially, it was a challenge to have large Spillover every sprint, but, now teams understand their capacity well and so the impact due to Spillover is reduced thought I reckon that it cannot be eliminated completely.

Grist for the brain mill:
1. Carryover (or better 'incomplete work') is a thing it Scrum - it happens!
a. Story pointing is a relative size ESTIMATION. You can’t accurately size every JIRA Ticket to ensure it fits
into a Sprint all of the time. Some things will get missed in Refinement which may lead to incomplete work.
b. There is a difference between understanding a JIRA (for example) Ticket and then developing code
in GITHUB. Sometimes a big difference. New questions come up that were not previously not thought of,
while the 2-week Sprint time box is ticking!
c. Carry over is used by seasoned professionals everywhere and not just by students. Incomplete work
is more accurate though, as it may not have to be completed in the next Sprint – but there is a price
for this. Carry over v incomplete work - semantics.
2. You can remove the Story from a Sprint but that hides the fact that it was incomplete How can you
apply inspect and adapt to hidden issues – they need to be front and center?
a.You don't need to remove incomplete work from the integrated Increment – it won’t be
there! The code won't have been merged, so is not releasable.
4. There is always usefulness in incomplete code. Code that is 50% complete is useful in the next sprint
where it can be completed, merged etc. How is that of no use?
a.You also ignore the fact that Developers have learned, gained experience, and generally expanded
their knowledge with incomplete work - all indispensable to Scrum!
b.You can discuss in Retro how to better Story Point, or breakdown a similar story in a future Ticket so it can be completed in a Sprint. INVALUABLE!!!
5. How is 50% completed code wasteful, you have a start! It can be buttoned up maybe in the next few days of the next Sprint.
6. Agree you don't have to carry over work to the next Sprint, it can be reprioritized with the remaining items in the PBI and placed appropriately.
The cost of delaying incomplete work is lost context which slows done productivity, so think carefully!

Really great article on CO: https://d-pereira.com/how-b... - not a big issue if you read this.

The only time I've not seen carry over happen is when Devs finish their work a few days before sprint, leaving time for acceptance testing and the like. If you don't want carry over, then you're going to have your devs not doing dev work. Or, if you don't ever want carry over, switch to Kanban, with no time boxing, there's no carry over.

There are some conditions, how often and likely carried over tasks will be reprioritised. If it's not often and likely, then it means these tasks need to be done and just keep going with it.
Even if there are some tasks that are carried over, however, if the team can meet the sprint goal, then it shouldn't be considered an issue.
in the scrum, what should we focus on? delivery value, complete sprint goal, or put ourselves into the framework perfectly?
from my team, I always focus on sprint goal, and our goals are never to be something like mark all tasks to done. our goal always are something reasonable, even not something can be delivered for a long running project. for example, "start coding bla bla", and it's nature of delivery.

however, if something hooked with performance review, there are plenty method can empty up sprint and get everything done, personally I don't think it's good for a company.

I'd say then you bring new itens to the sprint (considering your priorization), and consider an adjustment on the teams capacity for the next one.