How to respond when your lead asks for an estimate when requirements and scope have not yet been defined?

Question

EDIT: This question was originally marked as duplicate of 'How to respond when you are asked for an estimate?' I read over the answers, but I think my situation may be a little different, so I am completely rephrasing my question and elaborating on the context that I believe makes my situation a little bit different.

The answer above assumes that there is some kind of project scope, or an idea of what requirements there will be - and if not, at least some assumptions.

But my team is still in the discovery phase. We have not even officially kicked off on our project. We are still defining the problem statement, the user journey, and the experience roadmap for the project. So this means no defined scope, and no requirements yet.

The only assumptions I can make are that we're going to need to pull raw data from somewhere. My team lead has provided me with an excel sheet, and while I am perfectly comfortable working with that to provide a proof of concept, it is not sustainable as the primary source of information for the application because it is manually maintained. (And one of the ideas behind our project is that the user should be able to see the most up-to-date information available.)

He continued to ask about, "What are the steps needed to get to [that] point?" So I tried to get him to explain what [that] was. Instead of directly answering the question, he brought up an API that I had said we would probably need in order to communicate with some 3rd party software (as an example, I'm assuming). In the end, he was asking how long it would take to parse the excel sheet and JSON encode it - probably a couple of hours. He continued to ask 'what are the steps needed after that to get to a working prototype' - and I just don't know. There is literally nothing to go off of. I am working with the team to define a list of requirements, so I can get a better estimate, and we've determined that we can do that by next Wednesday, but my team lead wants the estimate tomorrow.

I could just go off of what my ideas for the application would be, and mark them as my assumptions, but at that point, if I start developing that, it could be a lot of time wasted, when I am simply asking for 4 days to work with the team as a whole. Not to mention - I believe designing with intent (and with the user in mind) is far more important than coming up with a list of ideas / assumptions about the app based on what kind of data is currently at my disposal.

What are my options, and what can I say or do to let him know that I can't estimate that based on nothing - or what am I supposed to do as an alternative? I don't want this to hinder the progress of the team, but we haven't even officially 'kicked off' yet - so I'm thinking this is rushed, premature, and eventually could be harmful to the overall development cycle and user experience. But I'm also new to this idea of 'professionalism' - so I want to try to be as clear as possible when I try to explain my [valid?] point?

Thank you, and hopefully this clears up my question.

Answer 1

He has asked you for an estimate "tomorrow" - tell him that it's not possible.

His natural response will probably be to try to pressure you into giving an estimate anyway, in which case you need to make it absolutely clear that he is asking you to lie to him.

In situations like this, sometimes it can feel that the most diplomatic and professional way to respond to estimation pressure is to make up a number which you are not truly committed to, because its "easier" to tell everybody what they want to hear. The reality is that situations like this aren't easy; avoid the temptation of providing easy answers - your responsibility is to provide correct answers.

The only professional way to handle the situation is to always tell the straight-up truth. You can tell the truth in a polite/diplomatic way - you are not setting out to hurt anybody's feelings, you are trying to help them understand the reality; which is that you do not have enough information yet.

Remember that estimates set peoples' expectations - one of the expectations being that your estimate is based on information that you don't have yet.

Never fall into the trap of telling people what they want to hear. Being stubborn about the truth is not unprofessional; telling people what they want to hear by lying about estimates is unprofessional.

Even when your direct line manager has pressured you into it, begged you, told you that he is going to catch hell from his manager, he is only doing that to cover his own back by shifting the responsibility on to you (if he is going to catch hell from his manager that probably means he has set some inappropriate expectations of his own - e.g. maybe he "promised" that he can "definitely" get an estimate from you tomorrow, without even asking you).

By giving an ill-informed estimate you are setting yourself up for a fall, and exposing yourself to the fallout of the inevitable wrong estimate which you provided.

People in management positions often don't like hearing the truth when it comes to project estimates. They will naturally ask you to explain why - and they might ask the same questions over and over, phrased in slightly different ways.

You already have several clear reasons why you cannot give an estimate; if necessary make sure you remind them of these facts every time:

• The scope is unclear
• The requirements are unclear
• The acceptance criteria is undefined

At the moment the only information you can give them is:

• Estimates relating to those requirements which are understood
• Estimates for the amount of time it will take to define the scope and requirements

Also, if you haven't yet done so, consider suggesting that the project could benefit having member(s) of the development team spending time with a project stakeholder to capture their expectations, including ideas about the UI/UX (But make sure you keep the discussions user-focused, avoid letting stakeholders get side-tracked into technical/design discussions - your team is lacking requirements input and not technical input).

This is a difficult situation (And managers/team leaders who put pressure on developers to provide impossible information are simply being unprofessional themselves - this is also, sadly, common); but it would be fair to say that an overwhelming number of projects start out in exactly the same way, and are often not run by people who respect or understand software development.

Answer 2

The biggest unknown you've left us with is how your team works. You're obsessing on the ill defined problem and forgetting what you know about who you are.

Who you are is a very significant predictor of how long the project will take, regardless of what it entails.

Ask yourself these questions:

• How long before you get sick of this project and pick up another or left for another company?

• How long would this project have to run before it bankrupts the company?

• How long before your customer would give up on you?

• Are you agile? Can you crank out something that does something in a couple of weeks without everyone expecting it to be perfect the first time?

This will shape what the project scope is even allowed to be. How much time your team is even willing to invest is not something to ignore.

Consider Excel itself. It's still in development. Been decades at this point. Think a single project manager claimed it would take decades when they started it?

So the best way to look at an estimation question issued in this phase when no one knows what all you're going to do isn't to obsess on what is too fuzzy to know yet. It's to focus on what you know. What does the estimate need to be to keep you in the game.

How much stuff are we going to take when we go camping? Whatever will fit in the car. I'm not buying a trailer.

This environment based approach creates a framework to work within when deciding what your team is willing to take on as the problem is defined. Sure, it's wild. But it's not meaningless.

Make clear what you're basing such estimates on. As soon as the problem based estimates become clear provide them and make clear what they are based on.

Environment based estimates and problem based estimates come from different directions and will always clash. Making them agree is a leading reason why good features get cut.

So when asked this question at this point, sure, your first answer is still

I'll get back to you.

But if pressed you can follow it up with,

This is not an estimate but I'm guessing we'll have 6 months before the plug is pulled. Have no idea if we even need half that but we'll start looking for features to dump to stay under that unless someone says we can have more time. Right now it's to early to tell anything about the problem.

The more experienced estimators are probably cringing at this point, You gave him a number! It's true, he'll forget everything else you just said and just obsess on the number. That's why you do this in an email so how you framed it can't be forgotten.

Why 6 months? Because I get sick of anything if I work on only it for 6 months. 6 months is a good period of time to rethink the project from the ground up. Any project worth this much angst about it's deadline should be at least this big. And if your going to throw random numbers around, well at least it isn't 42.

Now that's just the time. You also talked about steps

He continued to ask about, "What are the steps needed to get to [that] point?" So I tried to get him to explain what [that] was. Instead of directly answering the question, he brought up an API that I had said we would probably need in order to communicate with some 3rd party software (as an example, I'm assuming).

This is planing. At this level you look for milestones. Things you know will happen that you can report have happened. You don't have to get them perfect yet but it's good to show you're thinking of them.

In the end, he was asking how long it would take to parse the excel sheet and JSON encode it - probably a couple of hours.

I'm guessing this is a performance estimate and not how long it would take you to program the parser. Be sure your lead knows which you mean.

He continued to ask 'what are the steps needed after that to get to a working prototype' - and I just don't know. There is literally nothing to go off of. I am working with the team to define a list of requirements, so I can get a better estimate, and we've determined that we can do that by next Wednesday, but my team lead wants the estimate tomorrow.

Why? This is a wonderful push back question. Find out why tomorrow is important. Is he pressuring you because he doesn't want you slacking off or because something important is about to be decided?

The best way to push back from anti slacking pressure is to stick to your guns. Never be a waist basket full of wadded paper just waiting to be pushed down. Also, don't be a bucket of ice that will crack as soon as enough pressure is applied. If you must respond to the pressure, be a bucket of water. The more they push the deadline the more features flow out of the bucket on to the floor. Make clear what is being lost. Make clear this is not linear (for you mythical man month fans).

If there is some meeting he's headed for tomorrow and needs to be well armed then help him. Don't compromise a thing but find out what is really important to the pending decision and focus your estimating energies on that. Go to the meeting with him if need be.

Stand firm. Ignore all emotion. Tell it like it is. Find out what's really important.

Answer 3

You haven't even started or defined the project. Thus, it sounds like you are in the internal research and development phase. That is awesome. Those are the funnest projects to work. You could do what others have suggested and tell them it is not possible to give an estimate but then you'll likely end up never getting the opportunity to help define new products in the future. Your lead will just assign those tasks to someone else.

Your lead is fully aware that the project isn't defined yet. I'm sure what the lead is expecting is for you to start working out the scope and activities needed to build the product down to a level that you can give some estimates.

Obviously you won't get all the scope correct and you will certainly miss a lot of features. But what you've done will at least be the starting point for discussions. Most likely, your lead needs to just present a ballpark estimate to management so they can decide if they want to even pursue funding or not. If your estimate says 3 years but they have only 6 months of budget then that's what they want to know. If your estimate says 1 year, then they'll probably assume 1 1/2 to 2 years is what will really be required.

The way you cover yourself is to be very specific as to the scope of work you are quoting.

Answer 4

I have found common to be asked to give an estimate on something that is in the discovery phase. These types of estimates can be used to make a business decision as to whether or not it would be feasible to continue investing resources into a problem. Business units can often see a problem as simple, but the coders then uncover mountains of complexity. It is useful to get the coders' input by giving them the "big picture" problem that needs to be resolved, and then allow them to brainstorm on how it might be accomplished. They can then give a (very rough) estimate on the project, which is revised as more details are decided. If the client needs a shoppingcart and have budgeted 100 hours, but you estimate basic functionality will take somewhere around 2,000 hours, then they might decide to scrap the idea and sell on ebay instead, or ask for input on why there is such a disconnect.

The request might look something like this:

Manager: Hey, ABC is asking for an application that retrieves stock quotes from some service, formats them, and puts them on a dashboard.

I'd ask some probing questions, and then respond with:

Me: OK. Assuming that this is just a standard XML web service and we can plug the dashboard control into PDQ app that we already built, then I think it will take XYZ hours, roughly [which is probably 3x what I think it will take because developers are eternal optimists]. If they want searching and sorting, historical data, and an espresso machine, then I'm going to guestimate another NMO hours on top of XYZ. I can give you a better estimate once the requirements are more defined.

Ideally I would do this in email. The key here is to document the assumptions, be clear that it is a very rough estimate based on those assumptions, that it only accounts for what is in those assumptions, and then leave yourself some room in case you forget something material when developing those assumptions.