Hello everyone Today I'm sharing a real case about how one product team faced chronic problems in planning sprints and fulfilling commitments, and how we managed to fix it.

Problem #1: Burning tasks and blurred sprint boundaries

The first thing that caught my eye after several sprints of observation was the behavior of the product manager. He had a habit of regularly "throwing" new tasks into an already running sprint. The reasoning was standard: "There is a very, very urgent task from an important stakeholder*, it needs to be dragged into the sprint right now!"

• Example: The team has planned a sprint to develop a new feature A (score 13 Story Points) and fix bug B (5 Story Points). In the middle of the sprint, the product manager brings the task in ("Urgently correct the text on the main page, the CEO asked!", rating 3 Story Points). The team is forced to get distracted, the context is lost, and as a result, feature A is not completed, and task B is done in a hurry with possible errors. At the same time, the planned bug B remained untouched.
• Effects: This led to a constant delay in deadlines for scheduled tasks, demotivation of the team (the feeling that their initial plan was worthless) and the inability to focus.

Problem #2: Underestimating real performance (Capacity)

The second point came to light when analyzing the performance chart in Jira. This report clearly shows how much work the team plans to take on (Capacity in Story Points, hours, or other units) and how much it actually performs.

We saw that the team consistently "performed" by about 100 Story Points per sprint. However, time after time, sprint after sprint, tasks for 200 or even 300 Story Points were taken into the sprint backlog. Reports on completed tasks eloquently showed that the team was physically unable to cope with such a volume. This situation lasted for at least six months.

• Example: During planning, the team estimates its available capacity at 120 Story Points. However, under pressure or excessive optimism, they gain 250 Story Points in the sprint tasks. By the end of the sprint, it turns out that only 95 Story Points of tasks have been completed. And so it goes from sprint to sprint.
• Consequences: Chronic non-fulfillment of obligations, burnout of employees, loss of trust on the part of stakeholders and a feeling of hopelessness ("we won't be able to do anything anyway").

Solution: Open dialogue and realistic planning

Both of these issues were openly raised and discussed at the RETROspective (By the way, I recommend that you familiarize yourself with the frameworks for conducting retrospectives, this is a powerful tool!).

The team made two key decisions:

1. Sprint boundary protection: We agreed with the product manager that new tasks can be added to the active sprint only in an exceptional case (for example, a critical bug blocking the work of all users) and only after discussion with the team and removing an equivalent task pool from the current sprint. The main stream of new "urgent" tasks should go through the standard prioritization and planning process for the next sprint.

• An example of a dialogue with a product: "We understand the importance of this new task. However, the current sprint is already fully loaded. Let's see together which of the current tasks we can remove to make room for this one, or we can schedule it as the very first one in the next sprint, which starts in a week. How do you like this option?"

1. Planning based on real Capacity: The team began to focus on actual data about its performance (the same ~100 Story Points) when planning a sprint. Instead of trying to "cram in the impossible," they began to take on the work that they could actually complete.

Results: Predictability and increased speed

The first changes became noticeable within a month: the team began to consistently "meet expectations", that is, to perform almost all the tasks planned for the sprint.

And the most interesting thing happened a block later.

Contrary to fears that the team would "relax" and do less, the opposite happened.: The team's speed has increased by almost one and a half times! Instead of the previous 100 Story Points, the team steadily began to close about 140-150 Story Points per sprint.

This case clearly demonstrates how just two seemingly simple process changes have led to significant improvements.

Why it is so important to work with the Capacity of the product team (and how it can be visualized):

Working with the Capacity of a team is not just about numbers in Jira, it's about creating a healthy, predictable, and efficient work environment.

1. Predictability and trust: When a team regularly delivers on what it promises, it strengthens the trust of stakeholders. They can count on the team and make their own plans.

• Visualization: The graph "Planned Story Points vs. Completed Story Points" by sprints. Before the changes, there is a big gap between the numbers. After the changes, the lines almost match.

1. Reducing stress and burnout: Constantly overloading and breaking deadlines is a direct path to burnout. Realistic planning allows the team to work at a steady pace.

• Visualization (indirectly): You can track the team's "happiness index" or the number of sick days. Although there are no direct graphs of performance, an improvement in Capacity often correlates with an improvement in these indicators.

1. Quality improvement: When there is no rush and constant context switching, the team has time to do their job efficiently, think over solutions and test them.

• Visualization: Graph of "Number of bugs found after release" by sprints or releases. Expected decrease after stabilization of work with Capacity.

1. Improving focus and reducing context switching costs: Juggling multiple tasks, especially when new "urgent" ones are constantly flying into the sprint, is a huge loss of efficiency. Each switch takes time and mental effort.

• Visualization (conceptual): You can show a diagram where each "flying in" task breaks the flow of work on the main task, adding "switching time" before and after. Or the graph "Number of unplanned tasks in a sprint" – its decrease will be an indicator of improvement.

1. Real Productivity Growth (Velocity): As the case showed, when a team works with focus, without overloading and with clear priorities, its natural speed increases over time. People interact better, processes are debugged.

• Visualization: A graph of the "Velocity of the team (Completed Story Points)" by sprints. In this case, it would show stagnation or a floating result at ~100 SP, followed by an increase to ~150 SP.

Imagine a conveyor belt: if you constantly try to load more parts onto it than it can handle, or change the type of parts on the go, you'll get congestion, defective parts, and poor overall performance. But if you optimize the flow for the actual capacity of the pipeline, it will run smoothly and efficiently.

Key conclusions from this case:

• Transparency is the first step to a solution: Awareness and open discussion of problems (for example, in retrospect) are critically important.
• Sprint protection is not a whim, but a necessity: The team must be able to focus on coordinated tasks in order to achieve the sprint goal.
• Planning from real Capacity is the key to success: You should not deceive yourself and stakeholders by taking on a deliberately impossible amount of work. Data (for example, from Jira) is your best friend.
• Less chaos means more productivity: Eliminating constant distractions and overloads not only makes work more comfortable, but also paradoxically increases overall productivity.
• Trust and communication with the product manager: It is important to build partnerships where the product manager understands the limitations of the team and participates in realistic planning.