4 Technicalities That Can Ruin Your Sprint and How to Fix Them

Expectations (especially) from the newly formed scrum team are high. The methodology is still new for many companies, and once they are finally brave enough to make the switch, they expect a lot from the change.

It’s very easy for the scrum team to fail to deliver on its promise, and the failure can have many variants, all equally possible 😀.

Now, this article will not elaborate on scrum processes as such. Rather, I would like to focus on the ultimate goal of (just any) team – to deliver what was agreed on time and in quality. And in this case, the focus will be on more technical activities within the team that can lead to unsuccessful sprints and what could be an effective way of dealing with them.

Now, we will discuss technicalities that can ruin your sprint and how to fix them.

Backlog Generation Without a Solid Roadmap Target

Depending on the technical difficulty of the delivery content and how far from clients’ full understanding of the topics the content of the sprint is, backlogs can be one of the first problems hitting the team. This calls for serious complications like:

• Stories might be generated almost randomly and not by following a logical line, based on current flash ideas of someone hierarchically important, rather than based on some chronological plan. 
• Then the scrum team, on the verge of saving the consistency, will add their own stories to complement those already given. But ultimately, the result will be several big topics in parallel in the backlog.
• Since clients’ needs are always the priority, some of the important but too technical stories are postponed to deliver the functionality asked by the client.
• The team will then try to deliver, but the inevitable result is sprint content delivery that feels incomplete (or even buggy), and technical debt is expanding (leading to further stories into backlog).

Give it a few sprint cycles, and the problem will evolve exponentially into a situation where it’s no more important what is in the backlog because it is clear the content sitting low enough will never be resolved. There won’t be time to pick the stories; in each sprint, a batch of new stories is generated (and has higher priority).

How To Fix Backlog Generation

Approaching a solution here and convincing the partners to change is especially difficult, as this is the territory where the organization hierarchy has a considerable influence.

However, there are certain actions to be initiated, and even if they aren’t immediately approved, reminding them periodically and giving them into context with how the situation in backlog looks now and how it could be could lead to success over time:

#1. Ask for Concrete Roadmap Goals for the Team

This should be both from a short and long-term perspective. Make it clear what features must be done within the next few months and how the product should look one year later. A clear vision should be demonstrated thoroughly and paired with specific roadmap goals.

#2. Challenge Prioritization of the Features on the Timeline

It should never happen to leave the team balancing between several high-priority and high-complexity stories simultaneously. This will only lead to slow progress in everything instead of demonstrating substantial incremental progress in big topics.

#3. Revisit the Old Stories Regularly

Revisiting the old stories and getting confirmation if they are indeed still valid and what the priority of those is important. Map them into specific roadmap goals if they are still valid. Avoid unmapped stories in the backlog – that is a sign those stories have no clear business value or priority over them was lost over time.

Technical Debt Postponement

Technical debt is a state of the code (or its parts) in the developed software that is created as a side effect of prioritizing the speed of the delivery over quality. At times releasing new features within a sprint is an urgent topic, so the team may decide not to finish the stories perfectly.

However, in such a way, it still fulfills the major requirement of functionality from the business side. If not identified properly and in time, it can even be forgotten along the way and only re-discovered by hitting issues in later phases of the project.

The team itself is the most capable of defining stories for the technical debt created along the way. Unfortunately, such stories are often placed at the end of the priority charts, either by the client or the product owner. 

Accumulation of technical debt is a serious problem for the scrum team. It starts small but grows exponentially over time:

• New stories are beginning to be affected by unfinished issues from the past.
• Fixing a new bug in a system with high technical debt often leads to very complex resolutions because to fix the new bug, several other problems need to be fixed to get the processing into the stage where the fix can be made.
• The development team’s frustration grows as they see how it is more challenging to implement new features into a system full of unresolved technical problems that unnecessarily complicate the new functionality extension.

How To Fix Technical Debt Postponement

Consistency is the key here. Every scrum team shall develop a process suitable for its use case and stick to that no matter what. The process in question can be anything similar to:

Make a rule where at least 1 or 2 stories will be picked up from the technical debt backlog.

Reserve a percentage from the sprint dedicated only to technical debt-related tasks. This can be tricky, though, as it is very difficult to track such commitment. If going this route, it is probably better to define a concrete day in the sprint dedicated to technical debt activities only.

Define each 5th sprint or so to be reserved for catching up with technical debt stories. Fill in as much possible relevant tech debt content in that sprint. If it will be the case over time that there are not enough technical debt stories to work on right now, complete the rest of that sprint capacity with new features content. In any case, this concrete sprint shall be reserved for tech debt stories in the first place.

Too Flexible Sprint Content Change Before End of the Sprint

Scrum teams shall be flexible and ready for change, as it directly implies even from the Agile Manifesto, which is expected to be at the core of every scrum team.

But imagine a situation where the sprint content is changing every 2-3 days: 

• Stories are reprioritized, new stories come into the sprint, and other stories rarely come out. 
• The content is not only changing but also increases over time of the sprint period.
• Change in priority leads to a demotivated team, as they are then required to jump from one topic to another, increasing the stress and, in the end, leading to not delivering content. Not only for stories agreed to be part of the sprint during sprint planning, but often also the newly added stories.

It would be great if we could just give the freedom to the scrum team and then watch how the stories will complete, despite all the changes coming on the team during the sprint. The experience shows this is not going to work. The team will be distracted and overwhelmed by the content; over time, the sprint commitment will mean nothing.

It will become standard for the team to not complete stories inside the sprint; in the same way, it will become standard to carry over stories from sprint to sprint as a direct consequence. 

The client will then complain that there is no reassurance the stories put inside a sprint will be delivered within that sprint. Planning for features and roadmap goals will be off.

How To Fix the Flexibility of the Sprints

I believe sacrificing some sort of freedom for a few processes that will limit the flexibility of the sprints will significantly increase the reliability of sprint delivery. Such a process would include steps like:

• Do not allow an unorganized addition of new stories into the existing sprint. Have a review process in place, even if a very simple one, but a confirmation point that the new story is relevant and has higher priority than anything else already in the sprint.
• For every new story added to the sprint, remove an equivalently complex story from the sprint. Ideally, it shall be a story that was not yet started in the sprint or started only very recently.
• Do not add ad-hoc bugs discovered within the sprint automatically to the sprint backlog. Those are new stories to be estimated and planned for specific sprint inclusion. 

Insufficiently Defined Stories Leave Too Many Open Items

So you define the stories for the next sprint, the team goes through the clarification and refinement, estimation and tasks breakdown, and everything is ready for clear development, right? Well, not with unclear stories appearing within the sprints. 

Even if the stories are refined, the team will agree on some sort of estimations, even if nobody communicates unclarity with the stories. Poorly defined stories can be identified easily in such a way that the team is repeatedly returning to discuss the stories within the sprint.

This not only naturally prolongs the refinement time of the team, but it also leads to further scope change after the estimations for the sprint were done and content for the sprint was committed by the team.

Consequently, the stories are becoming larger and more complex than initially estimated. Also, the real development work on such a story will start much later than at the beginning of the sprint just because of all the additional clarification required. 

In most cases, this ultimately leads to an unfinished story in the sprint.

How to Fix Unfinished Story in the Sprint

If the team is served with too many unclear stories, it will become unmanageable over time, and project management can only wonder why each sprint ends with unfinished stories.

This can be a complex problem to fix. It mostly comes down to how far the product owner is with his knowledge from the development team and whether they can understand the team’s needs concerning the clear definition of the stories. 

Often, product owners are strongly functionally oriented people, and their connection to the development team is shallow. In other cases, the role of product owner is combined with the role of business analyst, which leads to even further confusion. So what to do in this case?

Schedule monthly calls for story preparation, where the features yet to be introduced into the sprints are to be deeply discussed in advance. Having a clear roadmap is the ultimate precondition for this to be successful.

Prepare analysis pages for such complex stories well in advance (before the stories are placed into sprints) so that product owners can easily define content-rich stories for development teams.

In very complex cases, it is a good way to dedicate time for design preparation before the topic reaches the scrum team. Specific SMEs from the team shall be dedicated to this activity.

By any means, do not allow the unprepared story to reach a sprint. Insist on its completion from a content perspective. This will create additional positive pressure on the relevant stakeholders to better prepare the stories for the team.

Final Words

Focusing on the good content of each story pays off greatly over time. Backlog management is an undefined territory for most of the scrum teams. Mapping stories into concrete goals and placing them into the context of higher-view targets is an underrated activity.

This list aimed to throw some light on those technicalities and hopefully help with orientation if some of the problems above are familiar.

Next, check out the best scrum tools for a startup to a medium business.