I'm at the beginning of a development project in a large organization.

The Functional Requirements are currently being worked out and documented with our business stakeholders by our Enterprise Design department.

I'm required to produce Technical Design Documents and manage the team to actually build the solution.

I'm wanting to try Evidence Based Scheduling, but as I understand, part of that is breaking the job down into small tasks that are less than 14 hours in duration, which requires me to have already done the Technical Design.

Therefore, can Evidence Based Scheduling only be used after the Technical Design has been done?

How do you then plan and estimate the time it may take to come up with the Technical Design?

2 Answers
2

Therefore, can Evidence Based Scheduling only be used after the Technical Design has been done?

If you don't know what you're going to build, how could you possibly know how long it's going to take?

So yes, you definitely need to have at least a draft of the design, and you need to let the programmers in your team to estimate their parts (as is emphasized in the article you linked to). You also need to have prior experience of comparable projects. Otherwise you don't know the relationship between your team's estimations and the reality. If you don't have prior experience, then you have to wait until you have some evidence to base the calculations on.

Then you'll refine the design as you go on, and the estimate will improve. At any point in time, your schedule will be as good as it possibly can; it's based on evidence, not on guess or hope.

Evidence Based Scheduling, or Story Points & Velocity etc. are just fancy words for a simple linear estimator: if it has taken T amount of time to do X % amount of the job, then there's likely (1-X)*T/X amount of time left - provided that the total amount of work stays constant. This sort of estimator is popular because:

You can estimate how long the technical design itself will take using evidence-based scheduling if you correlate the effort for past technical designs with sizes of their corresponding enterprise designs. It would be the same principle applied to different type of work.

There is really no specific limit how well broken down the work has to be. It's just the less you break it down, the less precise the estimate will be. With the enterprise design you can easily be off several times. But the business people often need at least something to know whether it's worth continuing the negotiations and risking the effort for design (if the project turns out too expensive) and correlating past project sizes with sizes of their enterprise designs is the best you can do for them in that case.