06/30/2017
in Methods
Reality check for another agile approach
Table of Contents
+++This post was migrated from our former blog about SCM-Manager Universe. Therefore, this post is only available in English+++
Some time ago we introduced the lean methodology #NoEstimates. We showed the basic principles and how to get started with it. Now, after some time, we want to comment on how to use this approach in reality. The time has come to figure out whether #NoEstimates is applicable in the real world and with real projects and we want to share some tips what you should focus on.
Important note: When it comes to #NoEstimates it is important to have in mind that it is not about the elimination of all estimations, it is about the reduction of estimation effort and changing their nature so that they become more natural. We already pointed that out in our first post, but it can’t be said often enough.
How to win a project without estimations
The best-case-scenario is that you know a client already for a long time and he knows you well and trusts you. In that case your cooperation should be based on a contract that is suited for agile projects. If you are in this great situation you might have agreed on an outcome based model or you committed to a time frame.
If you need an estimation to win a project, experienced #NoEstimates users only have to discuss the initial requirements, create a product backlog and count the number of backlog items to know how long the development will take – of course based on the current knowledge. #NoEstimates beginners could consult former projects that had comparable features to get an idea of a possible implementation time. If there is no historical data available you have to estimate, but try to stick to the #NoEstimates principles to reduce the effort for estimations.
How to account for dependencies between Stories
When implementing User Stories into a software product, there are often interdependencies between the User Stories and it makes sense to either develop them parallel or right after another. Before #NoEstimates you might have put everything that depends on each other into one big Story. With #NoEstimates you have to write your User Stories in a manner that you can develop one Story after another. That works well if you focus on an evolutionary and not an architectural approach, because that way each User Story can evolve several components/features, with their dependencies between each other.
Developing User Stories with the evolutionary approach is comparable to building a house. Each Story can contain changes to several parts, e.g. the foundation, walls, roof, interior and so on. The good thing about building a house with this method is that you always have an actual place to life. The disadvantage is that you have to rebuild or change things that you’ve already built. The architectural approach on the other hand comes without any rebuilding, but you can only move in once everything is completed. Translated into software development that means that the architectural method has lots of dependencies. You only have a working product after you finished the last Story and if you find out that you want to change something you might have to change parts that were already finished. Following the evolutionary method comes with much more flexibility, because your User Stories are not dependent on each other.
How to achieve that all Stories have the same size
#NoEstimates focuses on predictions based on historical data and not on estimations. To make predictions reliable you need historical data and to use historic data about your User Stories to predict implementation time for a new project requires a certain degree of comparability. In #NoEstimates this is achieved through time-boxed implementation duration.
Over time you will learn how to write User Stories that have about the same size, even throughout different projects. At this point estimations come into play, because you have to figure out if the described functionality can be implemented within a certain amount of time. Compared to “traditional” estimations, where you ask the question “How long does this take?” you ask “Can this be implemented within the time-box?” To answer either of these questions you need to discuss technical details, but the different focus of the second question makes it easier to answer for most people.
The learning process is supported by the approach to transfer uncompleted work of a User Story at the end of the implementation time-box into a new Story. So every time that happens you can investigate the reasons why the implementation took longer than expected. Usually it is one of the following reasons and this is how you can respond to it:
So again, it is about learning from the past to improve your predictions.
There’s still estimation, so what’s the fuss?
As mentioned before, it’s not about banishing estimations completely, it’s about only to estimate when it’s really necessary, when it adds value, and not as an end in itself. There is always someone who wants to know when something is done and if someone asks, you can either answer an exact date, and the other person will be highly disappointed once that date has passed without the promised completion, or you can answer “Based on our current plan and on our current knowledge, the implementation will be finished at this date.”. This answer implies a certain degree of uncertainty and that person might ask again once the promised date comes closer and then you can give an update.
The main thing #NoEstimates wants to achieve is to create trust between client and supplier by preventing disappointment caused by the false feeling of certainty in the uncertain world of software development. This goal is reached through these things:
Other methodologies like e.g. Scrum share the same goal, but compared to them #NoEstimates comes with less rules and a smaller overhead.
An agile approach with focus on reduced estimation effort
As already mentioned in the first part of this series and at the beginning of this post: It’s not the aim of #NoEstimates to completely eliminate estimations, its goal is to reduce the effort for estimations and to concentrate on discussing solutions. Even though the name of the approach might indicate that there won’t be any estimations at all. Switching to #NoEstimates requires changes in your mindset, in the way you organize your work and in your communication with stakeholders. Especially in the beginning, when there is not enough historical data and experience to make good predictions, it will be difficult to build trust. Therefore, it is a good approach to first change your internal processes to #NoEstimates, to gather data, before you use #NoEstimates in public.
