Agile Anti-Pattern – Budgeting Time

Those of us who worked in lots of different companies and Teams have probably heard these common questions during Sprint Planning:

1. How much time should we allocate to Bugs?
2. How much time should we reserve for Prod Release Support?
3. How much time should we block out for unexpected A,B,C scenarios?

And it’s no surprise, the Team is genuinely trying to figure out what it can tackle in the next cycle. Often, the Team comes up with some marginal answers, for example:

• 10% must always be dedicated to Technical Debt
• Please leave 15% room for Bugs
• Make sure that X percent must be reserved to help other Teams. 

These scenarios are endless. And all of these are anti-patterns, which we will cover in this article.

As a side note, we will cover the behaviors of Velocity driven Scrum Teams ( we recommend getting familiar with incorrect use of Velocity and its application as a Vanity Metric ), and non-Velocity driven Teams. Let’s begin.

Velocity driven Teams

Scrum Teams attempt to figure out how much work the Team is able to reasonably tackle during each Sprint. Because the Team aims to maintain a healthy Velocity ( consistency of amount of work that can be delivered ), the focus often is set on handling distractions – things the Team has to handle that are not part of the planned amount of work. This results in the discussion of what we call Team’s “Time Budgeting” policies or what some call as Story Point Capacity.

All of this seems reasonable when thinking about the Team’s solutioning to the problem, but before we dive into the abyss of wrongful thinking, let’s define the problem the Team is trying to solve:

• “How can the Team deliver a consistent and predictable amount of work in light of the unplanned events and unknown events that may occur during a fixed period of time?”
• “How can the Team continue to make progress on feature work to satisfy set goals without losing sight of the need to meet quality standards by addressing bugs, support issues, or tackling technical debt?”

If you re-read the problem statement and give it a deep thought, a eureka moment arrives. Oh God, we’re thinking about it all wrong! We are focusing on a consistent volume of work delivered, instead of the bigger picture – which is meeting the Goals!

We realize that it’s much easier to create a blanket policy of “X percentage must be going towards Y” than to thoroughly prioritize the backlog items towards a quality Sprint Goal. The reason for this is that most Teams simply have no ability to understand what is in their backlog.

 

Visibility and Visualization Challenge

What makes things worse is that tools like JIRA are partially responsible for this. They make it too easy to build out and keep long, unusable backlogs that make prioritization not only painful but frequently utterly impossible. Scrum Boards struggle with this as well, as they limit the viewport to only what fits the screen making it hard to see what’s ahead or far below.

To have the desired level of visualization allowing the Teams to comprehend what’s in the backlog requires custom views to be created. These custom views are needed for just one purpose – to have an ability to see a list of top User Stories, highest priority Bugs, and highest priority Tech Debt. Setting up these views individually for every Team in a Project is something most Teams simply do not do, and even if they exist most likely are severely underutilized if utilized at all. Which makes the Teams oblivious to everything in the backlog. 

Here is a quick test. Come up to each developer on the Team and ask a few questions:

1. How many Bugs are there in the Team backlog?
2. Which 3 Bugs are most important? Most painful or most critical for the end user?
3. How many Tech Debt items are in your backlog?
4. If you had to choose, which Tech Debt items would you handle first?

What you’ll find is that most of the Team members will simply have no answers to these questions. They feel that these questions are a responsibility of the Product to answer. Or answer along the lines of “I can probably find it in the backlog somewhere”. If that’s so, then what’s the point of self-managed Teams?

Engineers in this environment simply want to be left alone and often develop an attitude of “tell me what to work on and when and I will do the best I can to get things done.” Not by design, but by symptom to the Team’s inability to understand what’s important and what drives most value. Agile with micro-management is not very Agile at all – it goes against the very Agile mindset that quality Agile discipline promotes.

How can we fix this?

For Teams that would like to continue using Velocity based estimations – stop focusing the Team on Velocity protection. Let Velocity be the measure of forecasting, not measure of performance. Use it as a flexible measure of work volume limits, but not the Goal. Just follow a few basic rules:

1. Any work that the Team is forced to pick up after the start of the Sprint receives zero credit in Story Points during the Sprint unless all other planned work is completed.
2. Do not allow changing the Story Points of any work item during the Sprint and especially at the end of the Sprint. Once Sprint starts, estimations are final. You can re-estimate the Story for next Sprint ONLY if the work on a given item was never started.
3. And lastly, do not remove anything from the Sprint Backlog once the Sprint starts.

Implementing these rules, you’ll see a natural adjustment of Velocity of Sprint to Sprint based on the unknown factors. And planning the next Sprint using an average Velocity will balance out the numbers over time. It will become clear when the new work brought into the Sprint and Completed pushed out the planned work or not Started at the end of the Sprint. The tradeoff and interruption will be clear and visible. 

Quality Gates over Budgeting Time

The next recommendation is to switch the focus from Budgeting of Time to configuring proper Quality Gates. Most recommended are the High Bug Watermark ( also called Bug Waterline ) and a Tech Debt thresholds. 

These thresholds establish numerical limits for the number of Bugs or Tech Debt items the Team is agreeing to keep in their Team Backlog. When these limits are exceeded, the Team must stop all work and get Bugs or Tech Debt items under control by completing the highest priority items. 

This approach establishes a healthy discipline to keep tackling the highest priority items all the time, preventing them from accruing to amounts that are so numerous that they can no longer be managed. This is a much better process than allocating Time, because there is no indicator of how many things the Team can tackle with their 10% Time for bugs, or 18 Story Points. But it is absolutely clear what can be achieved when thresholds require the Team to fix top 3 Bugs and top 2 tech debt items.

---

Discover how Project Simple removes Agile Anti-Patterns and helps maintain quality gates applying Bug and Tech Debt thresholds. Contact us here.