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?”
“No.”
“Oh. Do you think you can get a perfect estimate this time?”
“No.”
“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.
Great! And, of course, once you do have data, you still have to remember that “past performance is no guarantee of future results” (as the mutual fund managers always say). But Projecting Into the Future can help answer the question of when the project will be done while acknowledging that uncertainty.
Hi
Like the post, experience this all to often!
One question regrading your statement on kanban and MMF’s and WIP … Not sure I follow ?
If the mmf is minimum or maximum would this not just change the number of elements to work on ( i.e. stories/tickets) , could you explain how this impacts WIP ?
Cheers
Cuan
Hey Johanna,
That was nicely summarized and straight to the point. Working in an organization that wants to be agile and lean, I come across similar situations every now and then.
Somehow these estimates – even when you have an experienced team capable of coming up with relatively good ones – tend to divide the customers into two camps: the ones who take the figure as a promise carved in stone (read: the estimate is lower than the customer expected) and the ones who want the figure to be rechecked (read: the estimate is higher than the customer expected).
Fortunately, there are also the golden few who understand the meaning of the word “estimate” and actually believe that the team knows best – even if the figure goes up at some point. It’s always (in my experience) easier to deal with a customer who trusts your team and prioritizes features based on the estimates given. Especially when the team is actively keeping the customer informed when changes in the estimated figures do occur.
Needless to say, I suppose, but I’m a strong proponent of continuous, honest and open communication.
Pingback: Agile Focus » Blog Archive » Against Managerial Time Travel
Hi, Johanna! Great post. It inspired me to a realization, which led to a rant:
http://agilefocus.com/2011/01/31/against-managerial-time-travel/
In some (many) cases it can be important to know the delivery date in advance because some other things are depending on that ( marketing, communication, customer release, …). I believe the question ‘When will it be finished?’ is a just question and should be answered.
If the choice would be mine, I prefer to work with a fixed date and a flexible scope. The fat is in the features. Build the application in a minimal way and only add fat if you’ve got time left, could be an approach to accurately predict when the project will be done.
Apropos of George’s comment, it seems to me that management types–at the CxO level –love putting Safe Harbor notices at the bottom of all press releases and annual reports. Here’s an example: http://www.ti.com/corp/docs/investor/harbor.shtml
What if we did that too?
—Michael B.’s evil twin
I don’t remember where I saw it first, but if that manager wants a date/time to hand his hat on, the advice I was given was to spend no more than 10 minutes on a guess of how long you think it should take, then double it and increase the unit. So two weeks becomes four months. Surprisingly accurate, I’ve found. Or do what our IT guys (seem to) do and hide behind a process that’s so mind-numbingly bureaucratic that you just know they’ve got slack built in just about everywhere.
Nice, but I still need to know when the project will be done. !!!
I think it is possible to tell when “a” project will be done vice when “the” project will be done. Tell the managers what you know in as much detail as they can tolerate.
I see a couple of gaps here.
If you base on what measured during the first iteration you’re still guessing especially when a project team has just been formed. Then to estimate how many iterations you need you use, well, swag. You have to split the work to features anyway and roughly estimate how many story points they’re going to take (or what T-shirt size they are etc.)
With Kanban it’s even worse – if you’re going to have minimal marketable features there’s a lot of work ahead before you’re going to be able to tell roughly how much time you need. You have to do pretty good WBS up-front to be able to tell, even if you have historical data to refer to. And by the way: to make better estimates in Kanban it’s better to keep features sized similarly than to keep them minimal marketable.
Estimating is never easy. Timeboxing or Kanban-style approach doesn’t make it much easier or much faster.
great! I am understood. the absolute clarity about the due date of a project is clairvoyance. New projects are always risks. It is a typical male problem, everything to know in advance do so.
God save us from pregnant men … if the months-9 can not be strictly adhered to the day, the project was red.
… unwinding? 🙂
About Kanban and MMF, you might want to look at Dimentional Planning.
It is a (different) way to think about stories.
I notice it helps people to realize that there are multiple ways to implement the same storie.
When developers and customers talk about roads. They talk about highways. Where in reality they might only need a cobblestone road. (And maybe only have money for a dirt road.)
https://www.inxin.com/wiki/DimensionalPlanning
In my opinion working for two weeks on a project, delivering something is the best way to spend your time to come up with a good estimation. (If you have 3 to 4 iterations of actualy work, then you get pretty good estimations.)
In the book software estimations, there is a nice estimation exercise I use a lot with teams. It asks people to estimate certain numbers. I use that exercise in my trainings.
Then I can actually show people how good (read bad) they are with estimations.
Then I calculate a team estimate. That is always twice as good as the individual estimates.
y
I wonder whether anybody can say upfront in the beginning of the project what needs to be done ! So if it can’t be said what is needed to be done not sure how anybody can say by when it will be done.