Just Another Agile Methodology

---

---

In the “Lean way of thinking” effort to estimate the implementation time for tasks, user stories or features, is waste, because it doesn’t produce value to the customer, it just makes people feel better. Therefore time spent on such activities should be reduced as much as possible. #NoEstimates is an agile methodology that helps you to focus on creating customer value instead of spending time on things that don’t create value.

Basic Ideas of the methodology

First of all: when it comes to estimations people often argue that estimating a project will help a team to better understand the project with its requirements, technology and architecture. So why would you want to get rid of that? The answer is: that is true, but it’s necessary to distinguish between the necessity to estimate implementation time and the discussion about technological solutions. Normally these discussions are only a side product of the estimation process, but they should be the main event. To understand #NoEstimates it is necessary to separate the estimation of implementation time from the discussion of technical solutions. Once you did that you will see that you took the first step towards #NoEstimates.

No Estimates and Agile

Just like other agile methodologies, #NoEstimates values the ideas of the Agile Manifesto. The idea is to create working software as fast as possible – and how is that possible? By reducing waste, i.e. time that is spent on things that don’t create customer value. Just like Scrum, #NoEstimates is based on a prioritized Product Backlog. The User Story with the highest prioritization is the next one to be developed. The difference to Scrum is that #NoEstimates is less prescriptive. It doesn’t require roles or artefacts and there are no sprints. In some way it is much alike to Kanban, where you always start with the next task once you finished the previous one.

Reduction of Estimation Effort

#NoEstimates doesn’t mean to completely eliminate estimations, it wants to reduce them to a reasonable amount and extent. Estimations on new topics are a more of a guess (or a “guestimation”), the result of a detailed estimation is not necessarily. The target is to move from asking questions like “How long will the implementation take?” to “Can this be done by tomorrow?” Often the answer to the second question can be given within seconds, whereas it’s likely that it takes longer to find the answer to the first one, because it expects an exact number.

Estimation vs. Priorization

Most of the times estimated effort is taken into consideration when it comes to prioritization. In those cases stories might be prioritized lower, because they require a long implementation time. If that is the case, the quality of the product is reduced, because stories with lower “functional priority” are implemented before high priority stories, only because they can be implemented faster. #NoEstimates wants you to focus on the real priority of stories. It wants you to focus on value first and then to figure out how to deliver that value as quickly as possible. Therefore the prioritization should be based on customer value.

Fixed Length

Another idea of #NoEstimates is to set a fixed initial implementation length for features. This way you can tell the customer for example, that each month one feature will be delivered. To achieve that you start to work on a new feature each month and when the month is about to end, you start to make the feature “sellable”, or shippable. When you concentrate on the implementation of the aspects with the highest customer value, you can be pretty sure that the delivered feature will provide value, even if not all Stories were implemented. In case User Stories are still missing you can describe a new feature that covers the missing aspects prioritize it and add it accordingly to the Product Backlog.

Reporting

There are different levels of reporting, e.g. on a project or feature-level and since there is no “one fits all” you should use different methods of reporting for each level. On a project-level you can for example use the “Rolling Waves” diagram, to show when features will be implemented. On a feature-level you can use the “Feature Delivery Metric”.

Other than in Scrum the reporting in #NoEstimates is based on historical data, not on estimated effort. Once a project has started and the first stories have been implemented you have data on how long the implementation of a feature takes in average you can forecast when a certain story will be implemented based on the current prioritization. Over time the forecast gets more and more accurate, especially when all stories have about the same size. Of course the forecast still can’t tell you when everything will be implemented completely, because you still don’t know all uncertainties, but the forecast allows you to say things like “Based on the current prioritization story XZ will be implemented by the end of calendar week 50”.

For that you can use a “Rolling Waves” diagram. The example shows that which features will be implemented within the next 5 months. The features 1 and 2 will be implemented within the next week from now. Features 5 and 7 within the next month, no. 10, 11 and 12 within the following month and features 21, 22, 25, and 27. The strength of this diagram is that it shows the increasing uncertainty.

To get an overview on how a feature progresses you can use the “Feature Delivery Metric”, which shows an overview of the completed and remaining stories of a feature. This is what it looks like:

The great thing about this metric is that it shows you the progress on the overall story processing, even when new Stories were added to a feature.

The aim of this agile methodology

Since the name #NoEstimates can be a bit confusing it’s important to keep in mind that the aim is not to give up estimations completely, especially not when you just started to use this methodology. The aim is to reduce estimations to a minimum. This can for example be achieved by reducing the story size and using a fix implementation duration for stories.

In the next part of this series we’ll show steps and actions you can take to move towards Estimates.

---

---