Sizing a potential project rapidly without formal estimation

Question

We have been asked by management to spend a very short period of time to "size" a software project - that is, to give them a very loose ballpark of time to implement the entire thing.

There are three major components (backend, ios, android), each to be the responsibility of one developer with domain expertise. Each person has been given thirty minutes to come up with a number.

We have been given a one-page requirements document, have extrapolated some coarse user stories, and a coarse flow doc. We're developers, not project managers, and there is no Project Owner as our company is in pre-sales on this project and wants to give the prospective client a loose number.

As developers we are uncomfortable with giving numbers on such a limited foundation. During development we generally do Scrum (stories, points, sprints, standups, velocity, etc), so once we're working on a project our estimates come easily and have some basis in reality. In this case though, there is no project yet and we're unsure of how best to proceed.

How should we handle this? And in future, how could our company do things better?

Answer 1

The art of giving a SWAG estimate

I have worked with many developers and development managers who are very reluctant to give an estimate with such limited information and limited time. They have been bitten too many times in the past. The main reason is even if the people asking for such an estimation understand the risks and give an assurance that it will be used carefully, when they pass those numbers on to others, they often tend to be misinterpreted as a fixed price delivery commitment.

On the other hand, management is not going to invest the time and effort to develop a more accurate estimate if there is not a potential business opportunity here. Even more importantly, the client won't invest the time to give you more detailed requirements if the order-of-magnitude cost is not within the range of the potential returns.

How do you break this deadlock? If your company has to do business, you all have to find a way to break this deadlock.

There is no silver bullet. Here are some suggestions:

1. Do your estimation as rigorously as you can with the available information.

2. When doing the estimation, call out any assumptions that you make explicitly in arriving at the estimate.

3. Use other projects that you have done to compare with this one. If this one feels larger than another project you did, revise the estimate upward accordingly.

4. Make a provision for design and feature changes: Something like, "As we learn more about the application, new requirements emerge. There will usually be some features trimmed or expanded. New features will be discovered and added." Add, say, 20% to the estimate to provide for such changes.

5. Give the high-end of the range: Typically client's finance people will most likely use this to get budgetary approval. If you give a lower number, it will be very painful for everyone to go back to the Board and ask for more money. But, if you save some money later everyone will be happy.

6. Use rough terminology: Something like, "With a team of 3 full-time developers, one full-time tester and half-time designer, Scrum Master and Product Owner shared with another team, we can deliver a minimum functional release in 2 quarters. Beyond that, the following 2 major features will take a quarter each."

7. Make design and feature choice recommendations that, if accepted, will save money from the high estimates.

Answer 2

First of all, you are not doing estimation. You are doing guesstimation. This is wiki article about this term.

Guesstimate is defined as an estimate made without using adequate or complete information, or, more strongly, as an estimate arrived at by guesswork or conjecture.

In other words: obviously, guesstimation is something between guess and estimate. You have to rely more on intuition when you are doing guesstimate.

Main point (as was said in other answers) to let the managers know, that it is guesstimation. It is not even estimation (as WBW said), It's more like forecast! Like weather forecast. With the same accuracy ;-)

Answer 3

Remember its an estimate, not a commitment.

I'd recommend the following questions around the estimate:

-Why are you being given such limited information/time to provide the estimate? -What is the estimate you are providing being used for? -Who is accountable for the accuracy of the estimate? -Who is responsible for the accuracy of the estimate?

Now to the estimate itself. Provide a confidence measure along with your estimate to communicate to the person using the estimate the risk involved in using a single number to make a decision. It could go something like...

"Well given that we have a 1 page document and 30 minutes to think this through, I estimate the time required to complete this work to be an average of 60 days plus or minus 30 days. I reserve the right to revise my estimate if new information is made available or if existing information changes."

Of course its also fair to push back and not provide an estimate if legitimately you feel you have very low confidence in the estimate you provide. After all, an estimate with 0 confidence is just a guess.

Answer 4

The software sizing purpose is usually to provide the data in cost benefit analysis process so that decision making teams (i.e. customers) can make a choices. It is better to know what the offers are from other competitors so that the team could provide the winning proposal. The estimation should be more like a phase approach as development team know more about the customers. Sample is as following: Usually the time frame could in line with each quarter pending on the deliver cycle of the team….

Phase I - Prototype:

• List or functionality
• Required resources
• Target timeframe for UAT

Phase II – Pre-Launch

• List of functionalities
• Size of BETA users
• Target timeframe

Phase III – Grand –Opening

• List of functionalities
• Size of users
• Target timeframe

Phase N – Revision - List of functionalities - Size of users - Target timeframe

(pending on if developers are allocated to multiple tasks such as QA testing or production support, at least 20 % extra time should add on top of developer's actual estimation)