Are there alternatives to estimation? (Software development)

Question

I am taking control of a small project for the first time, and want to tell if we can deliver our scope on schedule.

Most teams I have worked in have used story-based estimations. My experience of these as a developer has so far been rather poor:

• sessions were long, inefficient and unfocused, making them both expensive and demoralising
• they haven't worked well when the technology or the domain were unfamiliar
• teams I've been in haven't improved estimates with time
• many teams have social incentives to over or under estimate
• they are easy to turn into a stick, waved menacingly at developers. This too promotes over-estimation.
• they were, ultimately, guesses. They were rarely data-driven.

These experiences have been consistent across five companies I've worked in, including ten person startups and a thousand-strong megacorp. I don't think they're just anomalies.

Are there any alternatives worth trying? I am interested in Kanban and wonder if we could use historical measurements to continually hone our planning.

Finally, if estimation sessions are simply a necessary evil - how can I make them suck less?

Answer 1

For software development projects, fixed scope and firm estimations are a bad idea

I am afraid you are looking at this from the wrong angle. You said:

I am taking control of a small project for the first time, and want to tell if we can deliver our scope on schedule.

This is a failed approach. In software development, there are two inherent limitations to trying to arrive at a good estimate from a fixed scope:

• Requirements (scope) cannot be laid down in advance. They emerge during the project. This is very well established (known as scope creep). Don't try to fight it.
• All software development work is part R&D. You cannot estimate it precisely. There will be trial and error. Even if the domain is familiar, technology changes all the time (e.g., it is Angular one day and React the next) and vendors get acquired or go out of business. Again you cannot fight factors out of your control.

Go with one of the agile processes. Scrum is the most popular one. Work closely with your stakeholders. Show them working code every few weeks and get their feedback. Working together you can make it a success.

Additional clarifications based on good points made by @DavidEspina:

Arms length contracts fail: I am not saying that you don't estimate/plan at all. I am saying that you cannot do arms length contracts on the lines of: "You give me the scope, I will give you a firm estimate. You approve it. I go away and build the software and come back to deliver it when ready." That model is known to fail big time for software.

Dev team should get embedded with the client Product Management: The only way to build software is for the vendor to partner with the client. The dev team should function as a single team with the client's product management team who have the vision. This requires the client PM team to commit resources and time for the duration of the project. This is very hard to secure, but absolutely critical to the success of the project. Structure the project this way and then you can do the planning/estimation to meet financial (ROI) needs.

Answer 2

Since the other two responses have addressed other aspects of your question, I will respond to your interest in Kanban. I come from a company that builds a Kanban product (SwiftKanban). We use Kanban in all our product development and we have seen the benefits of data-driven forecasting rather than estimation, which we have dropped altogether! Also, I am personally a Kanban coach/ trainer. I have worked with a number of our customers helping them with Kanban implementation, usually in software and IT. So, I am very familiar with your challenge.

If you have historical cycle time and workflow data for this project - for all the different types of work your team may be performing, you might very well be very easily able to forecast with different levels of confidence when your team will be able to complete the project, assuming the requirements are reasonably stable - and there won't be too much of a scope creep. Using your Cumulative Flow Diagram (CFD) and your cycle time data, you can either do simple linear projection to see when the remaining scope might get done; or you can do more sophisticated modeling using Monte Carlo simulation (which is what we do) or other techniques.

Using just the CFD on your project's existing data, you can easily get a projection like the one shown below for our current backlog.

Here, simply based on the historical throughput of the team, we can project when the remaining amount of work in the backlog (the grey band's vertical jump) is likely to get done.

You could also do something as basic as look at your recent throughput - and get an approximate picture of when you are likely to deliver the rest of the work.

If you use modeling using Monte Carlo simulation, you can do different analyses. For example, you can look at how much work you can get done in the next 30 days given the past performance, at different levels of probability.

Or you can define the exact amount of remaining work (number of user stories, change requests, defect fixes, etc.) and get the probability curve of the likely completion dates.

Here you see, for a given scope on the left, the distribution curve on the right for the likely completion times.

Here is a more zoomed in look at the probability distribution curve.

Depending on how you can get the historical data, you can do this in a spreadsheet or use a sophisticated Kanban software - such as ours or others in the market.

The overall premise, of course, is that the team remains stable and the work mix continues to be similar.

Hope this helps. I'd be happy to answer any questions you might have.

Answer 3

While @AshokRamachandran is on target with the reasons why estimating SW projects is difficult, you still gotta do it. Notwithstanding the value of agile in helping to mitigate this difficulty, business people need to have some type of cost target with which ROI can be established so that project prioritization and investments are sound.

The primary issue I have witnessed is inadequate risk management, i.e., understanding the limitations of estimating this type of work as compared to more discreet, concrete, less ambiguous type of work like hanging drywall or laying carpet and similar.

One contributing problem, of many, is this tendency of estimating using discrete values instead of probabilistic values. If we don't understand the range of possible outcomes, then we failed at risk management. With probabilistic values, then we have a better under of what it might cost if things just don't go our way. Even with aggressive planning values, a discrete number on the left side of the probabilistic estimate, you then can fund your contingencies adequately.

In terms of it sucking, you are after all trying to predict the future. Even with more concrete type tasks, this is not done with the accuracy we all desire. Not even our daily commute can we predict with a high degree of accuracy and precision. So the suck is more about what people expect with an estimate...in terms of a guarantee. And this is on you, as a seller of services, to teach your stakeholders there is no such thing and to communicate early and often how you're progressing and what contingencies you're going to need.