#NoEstimates

After several posts around the topic of estimation and considering that estimations are often time consuming it is worth it to have a look at the alternative of not estimating at all. Therefore it is useful to become aware of why estimation is done or needed in first place. With that awareness you can asses whether these reason for estimating could be covered without the time invest for estimations.

Reasons for estimations

• Planning right amount of work corresponding to a team’s capacity
• Decision making based on effort/cost versus value/benefit
• Prioritization based on estimated effort and uncertainty
• Cost calculation and budgeting of projects and initiatives
• Forecasting for customers and stakeholder management
• Release planning
• Get an idea on uncertainty or “readiness” of a work item or user story
• Work item or user story sizes in order to fit in an iteration

With that in mind let’s have a look at whether these points can be satisfied without estimating units of work.

Planning the right amount of work without estimates

This is fairly simple to achieve with taking the count of work items or user stories done per iteration or timeframe in the past and calculating the confidence interval based on that historic data. As for this calculation the standard deviation and standard error is input, you can also use these parameter as an indication of your work item’s or user stories quality. the higher the standard deviation or the standard error is, the more likely there is some work to do on refining user stories or work items and probably apply a definition of ready.

Effort – Value decision making without estimates

From my point of view estimation doesn’t support decision making based on expected value. The best way to approach this point and get an idea of what the cost – benefit ratio might be, is to have business people and developer interact closely. The question which amount of work is achievable in what timeframe can be forecasted with the method described above. Whether the amount of work is appropriate in relation to the expected benefit is then a business decision.

Prioritization without estimates

As an estimation is only one of the parameters to consider for prioritization, the impact on estimates for the order in which the work items or user stories should be processes is weak. In the case of no estimations you are encouraged to prioritize based on other (even stronger) parameters, such as business or technical uncertainty, benefit/value, costs if a feature is not on the market (cost of delay) for example.

Calculating costs and creating budgets without estimates

Referring to Planning the right amount of work without estimates this point actually is not an issues. Calculating a confidence interval gives you a count of work items a team is able to complete per timeframe, sprint or iteration. With that and assuming you know roughly how many work items are needed in order to achieve the desired value, you should be able to create a budget for your project or initiative.

Creating forecast without estimates

Based on the confidence interval mentioned above, you are also in a good position to predict a target timeframe when a feature or product will be delivered with a certain probability. This forecast could then be refined from iteration to iteration, in same way as you would do it with estimated work items in a release plan. From my experience providing customers with a target timeframe instead of fixed deadlines or dates, is more important than estimates or no estimates. The customer and stakeholders need to be aware of the degree of uncertainty and that forecasts are forecasts and not a prediction of the future.

Release planning without estimates

This is very much in line with forecasting, where the initial forecast is your release plan. As the forecast, also the release plan must be re-worked and updated after each timeframe or iteration. As with forecasts it is important to keep customers and stakeholders aware of what a release plan is and that it might change at any given time. The changes shouldn’t be extreme but they are natural (unless you do re-occurring work only).

Getting a sense of uncertainty or “readiness”

Estimations alone never solved this point, it is the conversations and exchange of business and development people that reveals and removes uncertainty and gets work item in a ready-to-be-worked-on state. As important as these conversations is working with short feedback loop, which are covered by the agile principles of “Simplicity” and “Inspect & Adapt” amongst others. In order to remove uncertainty it is very efficient and effective when you put minimal effort to achieve a goal and get it validated as soon as possible.

Work item or user story sizes per iteration

Sizes of work items or user stories expressed in an estimation unit are in fact a good indicator whether they are fitting into a certain timeframe or not. Assuming having only the count of work items or users stories but not estimation unit assign to it, it will be challenging to predict how many work items to plan for an iteration for example. Therefore a regular collaboration between product responsible or business people and developers is necessary in order to get an idea how big or small a work item is. As this conversation needs to happen anyway iso that developers understand what product or feature should be implemented, there is a high synergy in also checking on whether a work item fits into a timeframe or needs to be broken down further.

From experience I can tell that you can go without estimating work items or users stories. In order to not estimate work you need to ensure that at least the above mentioned points are covered in order to work reliable and to have all the information needed for planning, budgeting forecasting and decision making.