Jen's Agile Cliff Notes - What is Carryover?

Carryover—what is it, really? Recently, there's been a lot of discussion around this concept. Many people experience the shame associated with it. So, let’s take a closer look at carryover: the good, the bad, and the ugly. We’ll explore when it’s acceptable, when it’s not, and how managing carryover can bring benefits to you, your team, and the company. Let’s dive in!

TL;DR (Though there’s a wealth of valuable information here)

- Carryover = deferred work into the next time period.

- It’s generally considered negative. It can make teams feel demoralized.

- How can we address it? Enhance planning for smoother sprints. Prioritize quality over speed—avoid cutting corners. Use metrics to diagnose issues. Communicate!

What is carryover?** Carryover refers to the number of stories that are postponed from one time period to the next. While it’s common in Agile projects, it can undermine predictability for both your team and the Agile Release Train (ART).

Each sprint should focus on delivering value! Do we consider carryover as a delivery failure?

https://www.linkedin.com/pulse/delivery-failure-how-do-you-deal-carry-over-stories-don-ewart

Unfinished work:

Is some carryover acceptable? That’s a topic of debate. It often leads to planning, quality, and predictability challenges for current or future work. It's not just about one missed commitment; it can create a cloud over the team. Retrospectives at the end of each sprint and PI should focus on addressing carryover and defining actionable steps to improve. Moreover, we need to remember that sprints can sometimes become artificial constructs that lose meaning.

It’s crucial to adhere to the Definition of Done for features, further enhancing our predictability as an Agile Release Train.

I want to share a snippet from a blog by Stephanie Ockerman on Scrum.org: (https://www.scrum.org/resources/blog/why-we-need-stop-talking-about-carryover)

“Why is partially done work waste? Well, it means you’ve spent time on something without being able to get any value from it. That time could have been spent on something else that allows you to get a return on the investment now. It is also waste because you may end up not continuing forward with that PBI in the next Sprint because something else becomes higher ordered in the Product Backlog.”

Why is carryover seen as negative? Incomplete sprints can hurt team morale for several reasons:

1. It may lead to dissatisfaction. Teams might push themselves to work extra hours to finish tasks and avoid carryover, but this isn’t sustainable over the long run.

2. Our metrics might look poor. There’s a common misconception that metrics reflect performance, but they should actually support transparency within the Agile Release Train. However, dev teams may feel uncomfortable with transparency.

3. Rushing may lead to shortcuts. Team members might find themselves hurriedly trying to complete all selected Product Backlog Items, leading to technical debt and a failure to meet the Definition of Done, which ultimately degrades quality.

4. Sprint planning becomes challenging. Carryover complicates planning for the Product Owner and creates hurdles for Business Partners as well.

5. Carryover often signals poor planning. This might stem from unexpected scope changes, incorrectly sized stories, or stories not properly broken down. An overcommitted sprint could also result from failing to account for time off or necessary training.

6. Lack of clarity might be a factor. Are team members encountering stories for the first time? Is there unfamiliarity with the codebase or previous coding quality issues?

7. Interruptions contribute greatly to carryover. Are there unmet dependencies causing delays? Are production bugs taking priority? Is your team providing necessary support to others?

8. Communication and collaboration gaps are common culprits. Raise flags early and often when assistance is needed—whether it’s with your team or others in the ART. Clear communication about blockers is essential!

Carryover isn’t ideal. Bugs can create additional work and disrupt flow, leading to chaotic sprints. What can we do as a team to minimize carryover? There are several strategies we can implement:

1. Develop a solid plan! Incorporate buffers, plan fewer story points into each sprint, and avoid introducing stories with known dependencies during the sprint. You can always add them once the sprint objective is met and dependencies cleared.

2. Your team should dedicate more time to grooming and sprint planning. It’s important to focus on creating a well-defined scope and acceptance criteria that every team member understands. Aim to size stories appropriately and split them when possible.

3. Review your Definition of Done for both your team and the Agile Release Train.

4. Improve prioritization and identify clear blockers. Escalate changes in priority through your Product Owner and up to the Product Managers. If you encounter blockers, don’t hesitate to ask your Scrum Master or Release Train Engineer for assistance; they are always available to help you when you face challenges or need guidance.

5. Prioritize quality and look for ways to avoid redundant testing by incorporating more automated tests. Utilize your metrics effectively. These can help with PI Planning capacity/load calculations, enable you to monitor burndown charts during the sprint, and assist in sprint planning using your team’s velocity for better forecasting. Measure your improvements, and as predictability is achieved, your estimates will become more accurate over time.

6. Communication is fundamental in Agile development, so make sure to discuss any carryover in standups and retrospectives. Explore questions like: Why was this story blocked? Can we review our cumulative flow diagram to identify bottlenecks? Is there a recurring issue that keeps arising?

Addressing these concerns can help reduce carryover and, more importantly, assist the team in frequently delivering valuable software.

You know what? There are times when it’s OK to not finish a story. But this entire article is about carryover, Jen, and why it’s bad! Yes, I’ll say it again, sometimes it’s OK to not finish a story. The focus should always be on quality and not an artificial deadline. Consider unfinished stories as learning opportunities rather than failures. With careful planning and honest communication, unfinished features should become rare occurrences.

When should you start on stretch work? While it’s tempting to get a jump start on the next sprint, only consider bringing in a story that can be easily completed by the end of the sprint (keeping our Definition of Done in mind!). This reinforces the need for proper backlog grooming, ensuring that stories are well-written and sized appropriately so they can deliver value during the sprint. Additionally, using “stretch” time at the end of a sprint is a great opportunity to work on bugs, technical debt, or training and research. Whatever your team decides, just ensure your sprint goal has been met FIRST—this refers to the team’s sprint goal, not individual goals. Avoid silos and foster a collaborative environment.

To recap, what are the benefits of minimal carryover?

1. Cleaner sprints help build trust between teams in the Agile Release Train (ART) and our Business Partners.

2. Improved quality arises from a focus on doing things right the first time rather than rushing to finish, which leads to fewer bugs later on.

3. Enhanced communication and collaboration occur, resulting in increased transparency. This builds trust that work will be completed on time and ensures that any perceived risks will be communicated promptly.

Jen’s Final Thoughts…

I want to leave you with these thoughts. Please, do not beat yourself up over carryover, but practice transparency. Definitely hold a retrospective on why a sprint goal was not met and reflect on that! Remember, each sprint is an experiment! Inspect and correspondingly adapt!

What steps will your team take to minimize carryover?