Some time ago, I’ve heard about a new movement (or approach), to do software development without using estimates. There are many Estimates vs #NoEstimates ongoing debates on the internet. At first, it sounds like a renegade approach. Like there are some rebels against corporate “written in stone” base principles and rituals. On the second though – maybe it could make sense. Either way, it definitely makes you think about all the dust raised by the topic.
I have participated in many different type of software development projects, which involved some kind of estimations. Those were either standard task time estimations or an estimations in a form of story points. But, recently, I’ve realized that I’m actually also part of a “no estimates” kind of a project. For years.
It was not like this at the start of the project. Back than we had MS Project files updated few times a week, based on our task (re)estimations. But at some point, customer decided not to do them anymore.
About Estimates vs #NoEstimates epic battle
It all started with a twitter hashtag #NoEstimates. It caused a huge debate over the internet whether or not we do need estimates when developing software. I’m not sure who is winning but I do not see this initiative as offensive but rather constructive. It is a good idea, from time to time, to challenge your routines and way of doing things, because there could be some better or at least more efficient ways to reach your goals. Maybe it makes sense – maybe not. But, we should keep being constructive and open minded.
The idea behind the #NoEstimates approach to software development isn’t to eliminate estimates but to explore other ways to solve problems without specifically asking ‘How long will it take’.
Developers are often asked to give estimations on a new project, on a new feature or on a specific task. Those estimations are always based on a feeling, a guess. They can be close to reality but are usually not. The main problem then is that the given estimations are not treated as estimations but deadlines. Due to this (default) behavior, it often results into:
- projects not finished on time/budget (CHAOS report shows that many project, especially bigger ones, have a big probability to fail)
- frustrated developers who are forced to work long hours (to meet the estimated guesses which became deadlines)
- customers who are not happy (they do not get usable product within the planned budget).
How this improve this situation? Maybe the change of the approach would give better results? There are some ideas:
- Challenge all your processes are remove any practice which does not any value to you or to the client. So, if estimations are not giving precise information (no value), just stop doing them.
- Establish a good communication and trust with the client
- Start small and deliver working software often, always bringing in a new value
- Check your priorities often and realign them when needed (work first on the most important parts of each feature; implement other less priority parts in the next iterations or even releases).
- You can use a story map to plan the project work:
- Work on splitting user stories which could give you better predictability and more grained prioritization
- Believe the data not the estimates. Use a pilot project for forecasting schedules. Measure how long it takes for the team to implement the stories of a pilot project/feature. Use this data to make a prediction how long the whole project could take.It should be enough to count each user story as 1 and do the simple math:
To get more info about this topic refer to Additional reads and references section below.
If you would like to get quick into more details I would recommend you to watch next presentation on YouTube: #NoEstimates—DevWeek 2015 Keynote by Allen Holub
How we stopped using estimates in our project
Our project started just like any other before. Initial draft architecture was made. Together, there was a companion MS Project document with the detailed plan for the first release. The team was structured with some 5 Java developers, 2 testers and a project manager. It was a new product client was eager to build, ship and start counting the money. On the other side, we wanted to prove that we are up to the challenge and capable of delivering such a product. All those intentions, from both sides, were totally fine and correct.
Estimates period
Start of each new project brings you and your customer to an unknown territory. You can do upfront preparations as much as you can, but still, there will be many challenges you will be facing on a daily basis. On a technical level, but also in communication, keeping team motivated etc. Aside to this, we had a project plan with hard milestones defined, which additionally made things more complicated.
We did our best to meet everyone expectations. Tried to implement the best technical solution. Reported weekly about our progress. Are we’ll gonna be late and how much. Who will be on a vacation, if possible and when, etc. Based on those data, MS Project document was constantly updated and sent to the client. It was very stressful time for all of us. This required to do some extra hours from time to time. We were asked very often ‘how long will it take’ to finish this and that which. All this really hit hard the overall team motivation and performances. Somehow we managed to get through, bring the project into production, though there were a lot of problems, hot fixes, server restarts etc. the system required a lot of efforts to keep it running. Some goals were reached but I think nobody was satisfied nor happy. Neither the client nor the development team.
“NoEstimates” period
Due to the complete situation, at some point, client started (or was forced) to think how to optimize the project. This should make the room for keeping the product live and further develop it – within the available budget. The outcome was that the team was reduced and the scope was a bit changed. The client was thinking to keep all the things which are bringing some value and to get rid of those which are bringing little or no value to the running project. One of the changes was that we also stopped doing updates to the MS Project document.
For managing the project we started to simply use just two JIRA issue attributes: version and priority. We have usually worked on one project version and always picked the tasks with the highest priority (within the version) to work on those. The client’s responsibility was to monitor what’s done and make/update issues priorities, to align with the current business needs and budgets. Recently the client started to create a JIRA epic for each week and link the issues the development team should be focused on that week. But again, issue ‘Fix for’ version and issue priority remained the main guidelines what to do next.
So we did not practice estimating each and every tasks like before. But that does not mean we have never made any estimation since than. From time to time, especially for a more complex features, we were asked to give a rough estimation how long it could take. The big difference is how we use this information (rough estimation) now, comparing how we used it before:
- The rough estimate should give enough info to the client is it worth to implement that feature, at the first place. Is the potential cost/benefit ratio reasonable. If not – we just did not implement that feature.
- On the other side, if it would make sense to go and implement the requested feature – we start with it. Then, after the implementation is started, we would cross-check the progress and assess the remaining estimation, from time to time. During implementation we get more details and knowledge what it would take to implement the feature, are our initial assumptions still valid etc. In general, we could have a better feeling how much effort is needed to finish. Then:
- If the result is more-less close to the initial estimation, we would just proceed
- if the remaining estimation differs a lot to the initial one, in a consulting with the client we decide 1) should we remove some not-top-priority tasks from the scope or 2) we extend time/budget for this feature (if it is very critical and if it makes sense to do, concerting other circumstances on the project).
To be honest, we did not use some prediction math, by counting the completed and remaining JIRA issues, in order to calculate expected delivery date. But we always had some kind of recalculated rough guess. This is definitely something where we could improve in the future.
I would also add here that there were couple of times we worked overtime but those were exceptional situations and are very rare. We just do not have a need to do long hours anymore.
The end result is that we have a running project in production, the client is satisfied, the team is working at no pressure and is able to maintain good performances. Although all this sounds like a nice and easy, believe me there are many challenging tasks and situations we need to deal with. On a regular basis. Technically and non-technically related stuff. But with a good understanding of what our goals are, having a mutual trust and confidence with the client, open and constructive atmosphere within the team – it is possible. It is possible to have a successful project and all project players satisfied. Be aware that all this does not come over night. It takes time and efforts to maintain the positive environment. But, in general, all you need to do is to regularly do small adjustments, which will keep the project on the right track.