How Long Would it Take to Build the Product?
A raw estimate of the time required to deliver is one the frequent questions asked by the customer. It is a question that makes an Agile team uncomfortable. On one hand, estimating an entire product functionality without actually starting work is ridden with flaws, however in many circumstances, it is a practical question which teams cannot ignore.
Jarrod Roberson mentioned that one should never estimate a complete project because it is completely against the philosophy of Agile. The best, which can be done is that the team should set a date depending on the cost, other constraints and the product owner(s) should decide on what needs to be done by that date. Pascal Thivent added that any upfront estimations would result in a fixed scope which is the opposite of Agile. Another extreme suggested was that Agile teams should never get into projects which involve upfront estimation.
However, does this work in the real world?
More often than not, Agile teams would bump into a situation where the client would need a raw estimate to make various decisions. Hugo Palma suggested,
I think every client wants to have have at least an estimate of how much the implementation of a given number of feature will cost him. I don't agree with people that say that if your using agile than you can't do this. Agile can be adapted to the real world where clients want to know how much money they're gonna spend on a project, or at least have a rough idea.
Mike Cohn mentioned that he regularly gets questions around estimating hours required to deliver a product. His first recommendation is to put off the analysis until there is adequate historical data or at least a few commitment driven sprint planning meetings have been done. However, there are situations which demand a rough estimation. For those, Mike suggested a technique of working with a sample set of the backlog. He suggested finding an average number of hours for stories of each size.
If we averaged the 1-point stories on their own we might find that they were 3.2 hours per point, and the 2-point stories that were broken into tasks were 4.3 hours per point, and the 3-point stories were 4.1 hours, and so on.
We can then multiply that average number of hours by the number of stories on the product backlog of each size.
Mike cautioned that this technique would inherit all the shortcomings that would have been introduced during task identification and estimation step. Rob Bowley commented that the sample backlog technique would not work as software development is unpredictable and techniques like this end up under-estimating the amount of work which needs to be done.
There is no justification for trying to do something like this. It will invariably end up hugely under-estimating the amount of work and considering the sums of money involved in software development, either do real financial harm to an organization or wreck someone’s career.
Matteo Vaccari mentioned that though estimation with a sample backlog might help with some numbers however, there would continue to be multiple unknowns like team maturity, history of working together, definition of done etc. which would eventually make this estimate less useful.
Another option in such situations could be to do Scope Limbering as suggested by Martin Fowler. The idea is to start with a fixed scope contract and gradually educate the client on merits of Agile and help them overcome the FixedScopeMirage. Rob Thomsett also suggested a game of double and add some which is close to what Martin described.
Thus, it seems that none of the techniques are complete in the real sense. Each of them suffer with some element of subjectivity and have their own pitfalls. However, their application to situations which demand a rough estimate might be helpful to the stakeholders to make relatively better informed decisions.
Estimation works - just use your head
Why do we need estimation?
Because we're paid to
- Solve problems which are not our own problems
- which cannot be solved usually without a certain amount of completeness
- and is expected by the people who have this problem, sometimes at a certain date.
If you need to do the website of the 2012 Summer Olympic Games, it's not good if it'll be ready at 2012 october, even if it's just a few months of slip. Also you cannot afford to not set up the full videostreaming by that date. Also, it's pretty likely, you won't swim for the 200m freestyle gold after your coding sessions, therefore whatever happens there is not your own problem.
However, you still have a bunch of swimmers, trainers, and billions of people as audience, who await your solution, on that date, not a minute further.
Some of the software engineers fail to do this unfortunately, yet it doesn't make it less important for those who wait for the solution out there.
Is it possible?
In my practice, I was able to do estimations with 10 percent +- error, on both directions. Sprint-wise it means a slip of a day, on longer term, it means a slip of [number of sprints days], or a gain of it. Of course with set dates, we just simply try to set the date 10% sooner, and it's usually OK.
How to do it?
I did a blogpost on FPA, the method I use mostly. I used it with an XP team, in RUP and Lean environments, it served me well.
But FPA is a hard beast. It requires you to know four things:
- your team
- your architecture
- your typical interactions (I won't call them processes, let's say: how things work usually with your client and within your team)
- your clients' typical problems
We used MVC mostly, and our client also had patterns of problems, which we were able to recognize. We looked back, and said: well,
- this is how much it took to build this form, and from that,
- this is how much we spent on writing the entity models,
- the HTML templates,
- the controllers,
- and this is how much we
- communicated with the client back and forth
- spent on QA
- spent on fixing errors recognized by QA (also a lot of efforts to recognize patterns in these and make it as close to zero as possible)
Therefore it won't work with a newly set up team, it won't work with a new customer, and it won't work if you don't have experience on the given field, or with the given toolset. And you have to think and measure. A lot.
It's hard. But once we've done that, we recognized that creating an entity itself doesn't have too much time-variety, yet the amount of tables handled makes a great deal on the complexity, and hence, product finishing time. Also for templates, we were able to say that it takes usually that much time for us.
You can actually measure these. It takes a little time-tracking app, or let's say an eclipse module, and if you do Lean, you measure pipe time anyway. If you don't have these, maybe a questionarie to your devteam (everyone brings individial numbers, not knowing about teammates, otherwise they affect each other), and just by simply looking up commit times in your version repositories usually solve the problem.
Deadline vs. Amount of work needed
FPA is primary an estimate on how much amount of work is needed. It doesn't calculate with human interactions. In my experience, in most projects these interactions took much more time than the actual coding. What you should work on, is to make sure these are small: we sometimes had problems with customers unreachable for two weeks and the given feature halted (we switched tasks, of course). With close customer contact, as per Agile, it can be minimized.
Re: Estimation works - just use your head
The problem is how to know beforehand that you need to build 15 pages with about 4 textfields each accessing 20 database tables.
Re: Estimation works - just use your head
- We chat with you for a week about what needs to be done, and draw things on whiteboards, then tell you how much will it cost, or
- We start coding on monday afternoon on the first week, but we can't tell you how much will it take
Agilist would like to do the latter, but perhaps, just perhaps customer preference would be the former.
Egads, just give the man an estimate
XP practices resonate very well with me, but it's pure fantasy to think brandishing "I'm Agile" excuses you from making thumb-in-the-wind educated guesses so business folks have some scenarios to plan with. I would never commit to a fixed price and timeline for a product, but somebody has to make the educated estimate as to the total (and ongoing) committment the guy with the bank account is making. That guy also needs to be told to be prepared for it to cost 2X that much...because it always does.
For me, when I make a moderately detailed list of a project's pieces and add them up, history has shown, that list added up to about 50% of what was actually required. Didn't take long for me to double my estimates, and things have gone pretty well since then.
This is not rocket science. It will not cause your excommunication from InfoQ, nor will your name be removed from the Agile Manifesto Signatory if you offer a client your best estimate of a total project. We know up front that estimate is wrong--knowing it is wrong is part of the estimate! At least you've reduced the error by some factor, and that can be communicated.
It Can't be Done
Re: It Can't be Done
Estimations...price and time
Now I am a big believer in atleast showing your attempt to answer these questions. Not doing so would be unfavourable and put you on the back foot.Certain caveates could be mentioned..but again its our best guesstimate with the info we have at hand. Unfortunately, this all happens when we are trying to win the business.
However, one thing that I always question in my head..is the customer. What difference does it make in the customers mind if we say a project costs $1000 versus it costing $2500. Or the project should take 250hrs versus 180hrs. I get frustrated when the clients are trying to understand how much they could be in for..when that figure is already somewhat large and anticiapted. I can understand if something expected to be rather cheap is then quoted as very expensive...but I dont understand ..when its expensive its expensive, when its cheap its cheap. At the end of the day clients want to know are we talking 100,1000,10000 or 1000 000 figures. Personally I dont think they care about the figure..they just need to have some way of sizing cost and time.
There has to be better techniques of getting this to customers so we stay within the 'ballpark'
Re: Estimations...price and time
Let's say you want to make an ice cream shop. You have 1000 dollars to do it, and you expect 1000 customers through the summer, and expect each to pay 2 dollars on average, so you make a profit of 1000 dollars at the end.
Then you decide you want a programmer to build that shop. The programmer is an Agile one, who can never estimate, and doesn't want to commit really, he'll lie a 900 dollars and that it'll be ready around april or may (it's january, let's say)
Then the programmer has other things to do, he slips. He also finds out making an ice cream shop is harder than he thought originally it was, despite 20 years of experience to build different kind of shops (but never an ice cream one, although he claimed it'll be easy.)
It'll costs you 1500 dollars to make it, and it'll be ready only in july, so, half of your customer base is gone, and you're in debt for at least 1000 dollars, in case the other ice cream shops didn't steal the summer for you.
Of course, sometimes it just has to be done, but if you have the choice at the beginning to build this ice cream shop or not, would you spend your money on it knowing what'll happen?