Over a million developers have joined DZone.

How Big Is Your Bucket?

DZone's Guide to

How Big Is Your Bucket?

· Agile Zone ·
Free Resource

Whatever new awaits you, begin it here. In an entirely reimagined Jira. 

A few posts back, I asked if an agile team should be expected to call their shots. In other words, should we expect that over time, an agile team should be able to accurately predict what they'll be able to deliver at the end of the iteration? My assertion was that predictability at the iteration level is the only thing that separates an agile project from total chaos. Without the ability to make small commitments on a regular cadence, we have no ability to forecast what we can get done.

I'm working with one team right now that has gotten really good at calling their shots... but... people keep getting pulled in and out of the team. Having a stable velocity is predicated upon the team working together, staying together, and learning how to estimate and plan together. The constant churn at the team level is making it really tough to establish a consistent velocity iteration over iteration. While the team is great at calling their shots, they are still not able to really say what they can get done... and by when.

I'm a big believer that if we can't get some idea of what we are going to deliver, and when we are going to deliver it... pretty quickly after spinning up a team... agile is almost a non-starter for most companies. Many of the companies I work with are not prepared to make an indefinite investment, with no idea of what they are going to get in return. Sure... agile teams fix time and cost, and vary scope to meet iteration objectives... but we have to have some ability to look ahead and manage the expectations of our customers. We have to have good data to help them make good decisions.

What I am really saying here, is that while calling your shots is essential, calling your shots isn't really enough. You also have to get good at understanding the size of your bucket. What does that mean? It means that iteration over iteration, I need to establish some kind pattern for how much feature functionality I can deliver back to the business. Out of the gate, I don't really care what the team delivers... or even how much they deliver... I want to know their delivery capacity over time. Not a hard fixed number, but a stable trend that I can base product decisions.

Over time, we will remove the teams blockers and help them deliver more effectively, but initially... they need to get good at calling their shots... and establishing the size of their bucket. So please... let me know what you think. Am I expecting too much from our agile teams? Should teams just be able to do what they can with no expectation of committed delivery? Even at the iteration level?

New roadmaps, more flexible boards, and dozens of new integrations. And that's just the beginning.  


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}