Fixed scope and resources - but I am being asked for an exact release date [duplicate]

Question

We have a project where the scope and resources are fixed.

We have a fully groomed backlog and a velocity, so from this I can work out a rough idea of when we may release.

As a team, we feel it is understandable that the business will want some idea of when it will be released.

My approach is to say something along the lines that based on the backlog size and velocity, we are looking at around 3 sprints until we can release say. But that is a rough estimate, and it is based on quality and any unforeseen issues that we can't predict.

The company though (especially the Product Manager) expects the team to agree to a precise date i.e. it's now early January, we commit to releasing it on the 28th March.

I am aware of principles such as the iron triangle, and how you can't fix all three sides.

Given this scenario, how do other development teams answer this sort of request, as in you have fixed scope, you have fixed resources, and you are being asked to give an exact release date? Do you refuse to give any estimate, give a rough estimate, or agree to somehow commit to a precise date?

Answer 1

I am somewhat puzzled; please bear with me. It would appear to me that you are in a pretty ideal situation that most dev managers can only dream about! You have fixed scope (who has seen in that in this day and age of constantly changing business requirements?!), you have a dedicated team (ditto!) and you have experience working with the team - so their velocity is known/ generally understood.

If the velocity is know, it must already take into account the quality they can deliver, the amount of rework they may have had to do in the past, and the 'net' delivery rate or 'net velocity'. You really can't do much about unforeseen issues as of now - except to provide for some contingency - which, ideally, you might be able to do from past experience with project schedules and overruns. Perhaps the scope might expand. Or a team member might fall sick for a week or two. A 10-20% schedule contingency might be in order.

So where is the problem? Or am I missing something? What possible unknowns are you worried about? I would think it should be possible for you - based on your release/ sprint plan - to forecast a completion date, with a contingency factor (or a confidence factor for a specific date).

As long as you provide an overall rationale, I am not sure what objections could your Product Owner or other management reps come up with for the plan you provide. They are asking for a fixed date, they will get one, with some contingency thrown in.

Not sure this is helping you any - since it is all pretty obvious - but hope it does.

I do agree with @Frank's suggestion - do keep prioritizing regularly with the product owner - giving them the benefit of the ability to change their mind about some of the priorities - and in fact even dropping some stuff altogether - while adding new stuff into the backlog, while keeping overall scope unchanged by and large. One of the key principles of Kanban, of which I am a big proponent, is this ability to reprioritize till the 'last responsible moment', focusing on the most important stuff at any point in time, delivering often and helping the customer get the important stuff on time.

Answer 2

Triage the scope, so that the most important features/requirements are completed first. Make the project "releasable" at least every week or so, so that if your funding is cut off mid-point, you don't have a complete failure.

By the way, this is standard practice for experienced development managers/leaders, as it is rare to finish everything by the deadline, if the deadline is fixed and optimistic.

Answer 3

You are a software developer! Don't answer misleading questions! Instead, help your manager to ask the right question. Then, answer the good question.

When will my feature be ready? is a misleading question. Examples of good questions are:

1. What's the probability of having my feature in three months?
2. What's the date by which I will have my feature ready with a probability of 70%?

Now, how would you answer these questions once they are asked? Well, you will have to use your records to build an empirical probability distribution of the random variable DevTime. I've done this myself and have found that Lognormal distributions have an excellent fitting.

A Lognormal distribution has two parameters: mean and standard deviation. Alternatively you can define them by providing mean and the dispersion P90/P10.

There are many approaches to find out good estimates of the mean and the dispersion. If you have data of other projects with similar scope, use them and use some curve fitting algorithm (e.g., BoxCox.)

If you want to be more rigorous you will need to build some model that should take into account the following uncertain factors:

1. Size of project
2. Focus - % resources you will allocate for the project (you have other tasks, right?)
3. Endurance - % of lines of code integrated that survived, say, >= 6 months
4. Speed - Lines of code (or # classes) produced by the team / day.

For the size I've used the number of classes involved as a proxy, have put a Triangular Distribution around it, and have multiplied this random variable by the (empirical) distribution of #menthods/class.

The focus is easier, I would start with 40%. You can use this parameter to negotiate with your manager.

What I've called endurance is measurable from your historical data. Again, don't use an average, compute the empirical probability distribution of this quantity.

Same for speed.

With all these distributions is fairly easy to build a probabilistic model and run Monte Carlo on it. That will give you the values of mean and dispersion you were looking for.

Once you have the distribution, plot it and teach your manager how to read it. The answer to all the questions that make sense will be right there.

If you don't have any data, or you don't have the time & resources to build the model I'm proposing, then play with your best "expert" estimates of the mean and dispersion and use some app to plot the resulting Lognormal distribution. Once you feel confident with one curve, use that for your poor-man estimations.

Bottomline: Don't answer silly questions. Turn them in good ones that will provide insights.