Hey there, Agile enthusiasts! If you read my previous post on Prioritization, you know how crucial it is to keep ourselves and our teams focused on what truly matters. But what happens when the workload begins to resemble an all-you-can-eat buffet—overwhelming and inevitably leading to a food coma? That’s where knowing your capacity comes into play!

Let’s face it: capacity is a real limitation we all grapple with on various levels: mental, physical, and emotional, to name a few. Gene Kim’s The Phoenix Project illustrates this perfectly, showing how unchecked capacity issues can bottleneck productivity and lead to “firefighting” instead of smooth, consistent work. Just as the characters in the book learn, we need to understand and respect our limits—whether it’s juggling meetings, handling feedback, or keeping up with Agile frameworks popping up like weeds.

Forced Priorities: You Can’t Do It All

Here’s the kicker: capacity forces prioritization whether we want it to or not. Just like choosing between binge-watching your favorite series or tackling that laundry pile, we often have to make tough choices with the time we have. A limited capacity means we can’t just grab every shiny new task; we have to choose what truly adds value understanding that when we say “Yes” to one thing, we say “No” to something else.

Borrowing Trouble: Capacity and Technical Debt

What happens when we ignore our capacity? We end up stretching ourselves too thin, leading to decisions that may seem harmless in the moment but accumulate into a mountain of technical debt over time. It’s like ignoring your credit card bill—you might treat yourself to a few extra lunch deliveries, but those unchecked indulgences pile up fast.

Pushing beyond capacity often leads teams to rush, skip refactoring, or cut corners. The snowball effect can be brutal: code quality suffers, bugs multiply, and before you know it, you’re dealing with more technical debt than you can manage. Managing technical debt with an understanding of capacity is essential for sustainable development, as outlined in Philippe Kruchten’s Managing Technical Debt guide.

Predictability and Sustainability

Understanding you and your team’s capacity is crucial for ensuring predictability and sustainability. Without a clear grasp of capacity, how can you expect to know what can be delivered consistently? Furthermore, if you’re managing to deliver consistently despite not understanding your capacity, how long can you maintain that performance before facing the inevitable burnout?

This is where our previous discussion on Prioritization ties back in. Mike Cohn, in Agile Estimating and Planning, provides helpful insights into balancing capacity with realistic work estimates. When we understand our capacity, we can make effective prioritization choices, ensuring our efforts yield results without burning out.

Prioritizing under capacity constraints is like shopping within a budget—if you don’t, you’ll end up with a hefty bill, or in Agile terms, unsustainable work expectations and burnout. When we know our capacity, we can “budget” effectively, ensuring that our efforts yield the best results without the burnout emotional starvation from the lack of a recent purchase in my online order history. By recognizing capacity, you can establish realistic timelines, minimize last-minute rushes, and keep your Agile team happily chugging along.

Tracking the “Team Pace” – A More Flexible Approach

Here’s where my approach to understanding team capacity comes in: team pace. By tracking team pace, I can see how much work my team can realistically handle within a specific time frame based on their actual availability. This helps me predict upcoming capacity with greater confidence and creates a budget of story points for the next iteration while emphasizing the importance of prioritization.

To find team pace, divide the work completed (story points for most Scrum teams) by the total available time (in developer days). For example, if a team of 10 developers works for 10 days, they have 100 developer days in total. If they complete 50 story points in that time, their pace is 0.5 story points per developer day.

With team pace known, we can project work for the next sprint by multiplying the team pace by the available developer days. So, if the next sprint has only 80 developer days, the goal would be 40 story points (0.5 pace x 80 days = 40 story points). For sustainability, I choose to project the same pace into the next sprint. This allows me to forecast what is known now into the future providing a measure of predictability.

Now, let’s contrast team pace with velocity. Velocity somewhat assumes a fixed capacity, suggesting that a team can produce the same amount of work consistently. However, we know that life happens: people take vacations, get sick, or face unexpected emergencies. Teams face layoffs, restructuring, and attrition. Team capacity naturally varies, and relying solely on velocity can create unrealistic expectations and pressure to meet outdated goals despite changing circumstances. Velocity also takes several sprints to fully understand, while team pace can be leveraged after the first sprint. Understanding changes in capacity is crucial to managing workloads effectively.

Expanding Capacity: Fixed, but Not Unchangeable

Now, here’s where it gets interesting—capacity is both fixed and expandable. Some days, we might feel like we’re running on fumes (hello, Monday morning!). Other days, we surprise ourselves by crushing a mountain of work.

Although certain aspects of capacity, like skill levels and experience, are fixed, they can change over time with patience and consistency. Just as an athlete doesn’t go from couch to half marathon overnight, your team will need time and support to gradually build their capacity. By fostering a culture of continuous learning, you empower your team to handle greater challenges.

So, how do we expand our capacity? Think of it as a gym membership for your mind and team. Just as you increase weights at the gym, nurture your team’s skills through targeted training and development.

Here are some strategies that have worked for my teams:

• Knowledge-sharing sessions: Schedule regular meetings where team members present on their areas of expertise. This fosters a culture of learning and benefits everyone by sharing insights and perspectives.
• Paired or party programming: This collaborative approach allows team members to tackle coding tasks together, sharing their thought processes in real time. It helps less experienced members learn from peers and builds camaraderie.
• Mentorship: Pair team members with mentors who can provide guidance and support tailored to their career goals. This one-on-one relationship fosters growth and offers a safe space for exploring new ideas.
• Coaching conversations: Engage individuals in discussions about their “growing edge”—the skills they wish to develop. Through open dialogue, help them set specific goals and create actionable plans for improvement.

Wrapping It Up

Knowing your capacity is not just a nice-to-have; it’s a necessity in the Agile world. Embrace it, prioritize like a pro, and keep that capacity expanding. Let’s ensure our teams thrive rather than just survive!

If you’re hungry for more insights, don’t forget to check out my previous post on prioritization and how it relates to knowing our limits. Until next time, keep Agile and keep up the pace!

————————————————————————————————————

I’d love to hear your take on this topic! How do you approach understanding and managing capacity with yourself or your team? Have you encountered challenges when balancing capacity with prioritization or technical debt? Comment below, and let’s discuss your insights and experiences!