3 min
Scrum attempts to ensure a steady completion of work using small batch processing and hence before every Sprint the Teams get together to figure out how much work can reasonably be completed.
In real life, even the best of Sprint Plans deviate from their original timelines. Changes in scope, distractions in form of bugs or support cases, discovery of unexpected complexity are just some of the reasons the volume of work aimed to be completed within the Sprint doesn’t get done. The result — carrying of the work over to be finished in the next Sprint.
And due to the frequent nature of carryovers, it has become a popular term in Scrum, often associated with the Team’s performance. Some people consider carryovers as a bad sign. Others, as a standard way of doing business.
We wrote on this topic in one of the previous articles, titled "Sprint Carryovers are Bad!"
However, in this article, we will be covering a terminology — “The Carry Forward”.
How we came up with Carry Forward
We are in a unique position having developed out very own Project Management platform, which we are proud to say "Yes, we put Jira to shame!"
The advantage in building your own project management platform is the a ability to start from scratch, re-think everything in project and product management, and analyze how teams work. As part of this, we came across interesting data and made some notable observations. That’s exactly how we came up with a term — Carry Forward.
Before explaining more, it would probably help point out that our approach to Project Management is drastically different to any other platforms. To date, project management platforms gave users a "Lego" set of tools to configure their own custom software development process. We went in another direction — building a prescriptive, opinionated solution that provides a quality software development process — out of the box. No plugins, configurations, or customizations — because nobody wants to waste time configuring a dev process, we just want to get things done.
As part of this vision, we decided to standardize how Teams present the information for Sprint Reviews. Instead of each Team wasting time to create custom PowerPoints for Sprint Review, we created a Sprint Review screen. A screen that’s automatically populated when the Sprint ends to summarize all the details. It lists work that was Done, work that was incomplete and hence Carried Over, it displays a progress chart, Sprint Summary description, as well as Retrospective Notes and Sprint Analytics.
Learning from our users, we observed lots of Teams start to work on a list of backlog items and then remove them from the Active Sprint. Sometimes, work was removed in lieu of a more important backlog item added at the same time before starting the work.
However, we also found instances where some work was already done, but the backlog item was never completed and was removed from the Sprint. And, as a result, the data on the work added and removed from the Team was never visible at the Sprint Review. Meaning, the Team could have spent an entire Sprint tinkering on something, but if they bumped it from the Sprint anytime before the end of the Sprint, all history of any activity on it would be lost.
Not only did this impact the data for Sprint Review, it impacted the factual data for our AI forecasting. We needed to do something about that.
What should we call the work that was planned, maybe even started, and eventually removed from the Active Sprint before the end of the Sprint? We called it Carried Forward.
What does Carry Forward really mean?
Carrying the work forward has a few flavors. Work that was moved back into the Backlog to be done at a later time and work that was moved to another Team — either as a way to have someone more appropriate work on it, or as a way to work on the next phase of development. Because one Team’s definition of done is another Team’s definition of ready.
Is Carry Forward a positive or a negative term? The answer to this question is “it depends.” Lets imagine that you’re managing a project and notice that work is constantly started and removed, or planned and substituted mid-Sprint. This could be a sign of poor prioritization, a sign of a Team gaming the system by impacting the end of Sprint metrics, or a sign of an appropriate and Agile action of focusing on what’s important.
Therefore, in our Sprint Analytics, the Team can always see this as yet another metric, helping raise the right questions, to have a clear understanding how the Team works, and how it can improve.
What do you think about Carry Forward? Is this something you track? And, would it be something valuable for you to see to help your Teams?
