I was talking with a new-to-agile project manager, who said he needed take the first iteration to do design and estimation. I asked why. “Because our management needs to know exactly when the project will be done.”
“Do you think your iteration of design and estimation will provide you a perfect estimate?”
“Uh.” He paused. “From your question, I’m guessing you don’t think it will.”
“I have never found that spending two weeks will provide a perfect estimation for anything larger than a 2-week project. But I could be wrong. Have you been able to before?”
“Oh. Do you think you can get a perfect estimate this time?”
“Then why would you spend your time doing an estimate instead of producing something, learning from that and bettering your gross estimate?”
“Because my manager needs to know when the project will be done!”
I feel for this guy. I do. I understand why his management wants an estimate that’s better than a swag (scientific wild tush guess). But you can’t always give your managers what they want. You might be able to give your managers what they need (with apologies to the Rolling Stones).
If you are starting a project and you are using iterations, you can do a gross estimate of the entire backlog, do one iteration, see what your velocity, and guess at how many more iterations you will need. Your guess is dependent on the backlog not changing, on your gross estimate being right, and on your initial velocity being a predictor of future velocity. Put like that, your managers will realize your initial estimate is a guess, and they may well want another estimate in another iteration or two or three. That is a very good thing. You can do that.
If you are not using iterations, you can do a swag, and then know that your estimate is wrong, until you have some delivery of some sort. Until you have some part of your product working, you have no idea how far off your estimate is.
If you prefer to use kanban, that’s fine, as long as your features are minimum marketable features. If your MMFs are maximum marketable features, you have no idea when you can be done because you are not limiting work in progress. Kanban is great for limiting work in progress for the entire team, and for not piling up work where people can’t finish it. The team can’t proceed until the team finishes work.
Once you have data, you can see when the project will be done. If that’s after several timeboxes, great. If that’s after some number of minimum marketable features, great. But you can’t really provide an estimate without data. Otherwise, it’s just a swag. And if you want a swag, I can give you any swag at all. It won’t mean anything, but I can give you one.