Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
We are having a disconnect between development and business needs.
Business is asking me to produce an accurate list of deliverables for a fixed date and development being difficult to predict is pushing back saying that can only produce a list 80 or 90% accurate.
So my question is, how do we solve this problem? How to provide an accurate list of deliverables weeks before they are completed and fully tested?
The disconnect is that neither side understands the situation; business wants what it wants when it wants it and thinks that IT can just magically deliver regardless of the features and timeframes.
While it's nice for the business side to have that much confidence in IT, it is a 'fairy godmother syndrome' in action. IT is not Santa Claus, there are no magic elves, it all takes planning and work and time and experience, and it's never perfect.
Time is incompressible. It cannot be created. It can certainly be wasted though.
Accuracy can only be measured after you're done.
Confidence is a statistical measure based on estimates and black magic math.
If you say "we can have these 10 features done in 3 months with a confidence level of 80%" this implies a better than 97.79% confidence level for each feature [they multiply, it's not an average]. What you probably mean is "8 out of 10 of us think we can do this in 3 months", which is not the same thing.
All that aside, this is a fundamental project management issue, not limited to IT. It has nothing to do with Agile. There is no crystal ball that will guarantee an accurate list of deliverables months in advance. Businesses must understand the variables, but most of all the risks involved. IT must deliver the estimates along with the risks.
There are methods to help measure and improve, but gnat's comment about steady improvement is the most practical immediate advice - if the business side will go for it.
If not, then you guess, promise, fail, apologize, measure, and improve, like everyone else. And just when your numbers start lining up, the team dynamic will change and throw them off again, or the business will shift direction into new domains, restarting the learning curve.
That's the nature of project management.
Joel Spolsky wrote a good blog about making schedules - Evidence Based Scheduling
Software developers don’t really like to make schedules. Usually, they try to get away without one. “It’ll be done when it’s done!” they say, expecting that such a brave, funny zinger will reduce their boss to a fit of giggles, and in the ensuing joviality, the schedule will be forgotten...
The main ideas are -
Break down work into really small tasks which can be estimated in hours (he suggests maximum 16 hours).
Make sure all devs record their time against tasks and use the difference between recorded time and estimated time to correct future estimates.
Regularly recalculate your schedule based on the latest estimate/recorded time data, so you can see well in advance that your ship date is slipping and adjust your date/feature set accordingly.
It's the sort of process that would probably require a few releases before it became really accurate, so it might not help you right now. It may however be something to consider implementing and might help you push back on the demands for a definite release date for this release.
If nothing else it's an interesting read as is most of Joel's blog.
Take 80% of the features and give a 99% confidence level given the original timeframe.
For example:
If there is a 80% confidence for 10 features in 3 months, then give them a list of 8 features (80% of 10) for a 3 month time frame with a 99% confidence.
You should also show what the risks are, how you will mitigate them and what happens if the risk occurs.
Update
Many times the business side is asking for estimates and confidence levels in order to make proper marketing decisions.
I love Joel's blogs. I wish more companies read him and understood the principals behind proper development project management and time estimations. Unfortunately many companies are still stuck in a manufacturing mentality - "If you can build 1 part in 1 hour, why can't you build 10 parts in 10 hours?"
As proper engineers we read books, go to sites such as stack exchange and participate in the community. Proper time estimation is as much about math as it is people management. You have to manage your stakeholders (bosses, customers, project manager, etc) while not over burdening your engineering staff with impractical schedules and feature lists.
Too often management sees the end goal and wants to understand the time and effort to get to the finish line. This is where projects fall apart and estimations become fiction. Build a project plan in which your confidence level starts high and ends low.
If there are 5 features and 6 months your confidence scale could look like this:
Feature 1: 90%
Feature 2: 80%
Feature 3: 60%
Feature 4: 30%
Feature 5: 5%
You feel very confident you can complete Feature 1 in 6 months. However as the features start adding up you feel less and less confident you'll make it through all 5 features given 6 months. As the project progresses and features are completed this confidence scale is adjusted. As you can see the only way to be reasonably confident in completing the project on time is to only release Feature 1.
To give a significantly high confidence level in completing a set of features, the confidence scale needs to extend out until each of the required features are within a desirable range and only at the last feature does the confidence start slipping. This brings in it's own difficulties though. The longer a project takes the high the risk. This is why I like the idea of SCRUM.
Disclaimer All the numbers I have given are made up based on analysis of a fictitious company. Each engineering group is different. The numbers are here only to illustrate that as the features increase the confidence level significantly drops.
There is actual math that should be used when performing these scales. I have willfully and shamefully decided not to use math to ensure my numbers add up.
The one line answer
There is probably nothing you can do now, but you can plan to improve over time.
An analogy
Ask your business partners how long it will take them as a team to mow the grass surrounding one of the hotels in your town. Most likely they won't be able to do it, because they've never mowed the lawn of a hotel before. However, if they mow that lawn, and then you ask them to estimate how much to mow the yard of another hotel, they will be able to give you a slightly better estimate.
Keep doing this over the course of the whole summer, and after a few months they can probably tell you with a fairly high level of accuracy how long it will take for any hotel, once they've seen and measured the hotel in person. Even though every hotel is different, they will be able to break the job down into pieces ("mow around the pool", "mow around the entrance", etc), estimate each piece reasonably accurately, and thus estimate the entire job.
Plan to do better
There is no way to look at a specification or idea and estimate how long it will take. However, if you are able to break a project down into a set of stories and accurately estimate the amount of time it will take to do each story, you can then use the historical velocity of your team(s) to predict when those stories will be done. With a mature team this can yield fairly accurate results. You still won't be 100% correct, but the probability is high that you will be pretty close.
The trick here is that this only works well for experienced, mature teams. There are two variables in play that are hard to stabilize. First, your team needs a stabile velocity. That is, they need to be able to regularly produce X units of work in a fixed period of time. Once they are able to do that, then it becomes much, much easier to estimate new stories because they have a frame of reference ("we spent Y time on feature A last month, and feature B is about as hard as feature A, so we expect to spend Y time on feature B, too").
When you have that stable velocity, you need to use what you've learned to estimate stories. This means that stories need to be small, no more than few days worth of work. Once you are able to accurately size your stories, the deadlines largely become an exercise in mathematics.
All that being said, even the best of teams can't predict what will happen over the course of several months. Make sure your releases (even if only internal milestones) are relatively short. Work on a couple months worth. Hit that goal, then use the data to figure out how much you can do in the next month or two. Hit that goall, then lather, rinse, repeat.
Summary
One final thought
This isn't a software engineering problem, and this isn't a business team problem. This is an organizational problem. The organization needs to learn to work together to determine how much can be done by what date. It's not you versus them, it's us.
This comment is far, far too short to properly explain why estimation is hard, and how to do it better.
Software Estimation: Demystifying the Black Art by Steve McConnell is the right length.
Often referred to as the “black art” because of its complexity and uncertainty, software estimation is not as difficult or puzzling as people think. In fact, generating accurate estimates is straightforward—once you understand the art of creating them. In his highly anticipated book, acclaimed author Steve McConnell unravels the mystery to successful software estimation—distilling academic information and real-world experience into a practical guide for working software professionals. Instead of arcane treatises and rigid modeling techniques, this guide highlights a proven set of procedures, understandable formulas, and heuristics that individuals and development teams can apply to their projects to help achieve estimation proficiency.
Discover how to:
- Estimate schedule and cost—or estimate the functionality that can be delivered within a given time frame
- Avoid common software estimation mistakes
- Learn estimation techniques for you, your team, and your organization * Estimate specific project activities—including development, management, and defect correction
- Apply estimation approaches to any type of project—small or large, agile or traditional
- Navigate the shark-infested political waters that surround project estimates...
Just remember that in most organizations, the estimated delivery date tends to be the first date that nobody can prove it won't be done by. That is part of why most organizations tend to underestimate schedules by a factor of 2, and manage to hit that schedule only because they strip out an average of half the promised features.
nothing. For any other answer they would have to change the question or you would have to start to lie to them.