How Big Is Your Bucket?
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?
Comments (6)
Dave Rooney
Hey Mike,
Isn't velocity intended as something that allows the team to figure out how much work they can do in an iteration? The way I learned it, you use the velocity trend and/or average to extrapolate on a burn-up/down chart when a team will complete something. Nice and simple.
What I've seen and experienced over the past 4-5 years is that people either overthink velocity and start using it as a measurement of the team, or they ignore it and try to do more work that the "bucket" can hold.
It almost seems to me that the software industry rejects simple answers to, wel, pretty well anything. ;)
BTW, sorry I missed meeting you at the conference. I saw you a couple of times, but one of us was busy with someone else every time.
Basil Vandegriend
I think asking for predictability is quite reasonable for the reasons you outline. But I've been finding it quite challenging to get reasonable predictability from my team. By focusing more effort on becoming predictable I think we can improve, but note that it takes effort away from just producing desired business functionality. I'm now debating to try for low-precision predictability rather than high-precision as a compromise.
Mike Cottmeyer
Hey Dave… I wish we could have talked to. Next time just walk up and interrupt me ;-)
I agree with your assessment of velocity… it is a team based assessment of how much work they can get done. I just want the number to stabilize at some point so the team can get good at being predictable.
I also have a whole 'nother line of thinking that talks about risk, and when should we reasonably expect a product to be risk free enough to be predictable. The problem often is that we don't attack risk early enough in our product development to get velocity into a steady state.
Thanks for the comment!
Mike Cottmeyer
Thanks for the comment Basil… I think I am going to do my next post on reducing risk early… maybe that will help with your problems. I don't want you guys to put more effort into estimating, anymore than I want you to get better at telling the future ;-)
Matt Block
I have to agree that understanding the size of your bucket is very important. How else can you possibly put together any sort of a reasonable roadmap? I also like that you pointed out the fact that getting to that stable number is much more important that what the number is. I don't care if the number is 50 or 10 or 1, I just want to know what the number is so I can plan accordingly. Once I know what the number is the team can start coming up with ways to improve the number, but until that number starts to become consistent it is very hard to identify ways to improve it.
John Goodsen
Hey Mike, I view Iteration commitments to the business as big batch sizes. With fixed iterations, teams can easily get distracted playing the game of what fits into their iteration bucket rather than focusing on flow. I'm thinking that (using Kanban) if we can get a team to think about making a really small commitment, a commitment to when the next story will be delivered, would be a huge win to most teams who have trouble estimating even a day or two of work (which is like most of our industry).