No estimates

I was at a meet-up from the Software Craftsmanship Zürich on the topic of “No estimates QA session” with Vasco Duarte. I read a few things about “No estimates” (aka “NE”) before on Twitter. I got questions on how this should or even can work in real-life. This article is a summary of some of the things I took away from that meet-up.

Estimates don’t work in large scale

The main reason for the whole #noestimates idea is the fact that in practice estimates do not work. If a team matches a deadline it’s normally not because of the precise estimates they did but because of smart human being. We as humans will cut corners and try to improvise so we can make the deadline.

I can confirm this by looking at my own estimates which are based on my 25+ years in software development. My estimates may be better then the one others do as I tend towards more pessimistic estimates then most developers but they still suck regularly. This is because we as humans are bad in estimating time for complex or large tasks. We are also bad in predicting the future far beyond.

Vasco showed an experiment that a team at Microsoft did. They set up a new project to develop some peace of software. The timeframe for this was about 10 months or so. They did the hard work and estimated the entire backlog using story-points just as we know from agile/scrum practices using values from Fibonacci  (1, 2, 3, 5, 8, …). Then they did the same only using the values 1, 2 and 3. So scaling was different. Finally they set all stories to the same story-point value. The result was that all the forecasts showed a possible release-date within the same two or three weeks over the whole period of ten months.

The project-leader then came to the conclusion that they don’t need estimates. They are useless and the team can spend the time for more useful things instead like refining and slicing user-stories. Instead of estimating each user-story they now just count the user-stories and they know about how many user-stories they can do per sprint/iteration. This is done way easier and faster then estimating each story.

Estimates vs. forecasts

No estimates doesn’t mean you don’t have forecasts nor burn-down charts. You can do this based on the count of stories instead of story-point values. This further means that you don’t try to predict the future by guess-working but instead by measuring your work and doing a forecast based on that measured data (= number of user-stories).

Size of a story and slicing

Humans are very bad in estimating big tasks but we are better in doing so for smaller tasks.

In agile but also in no-estimates user-stories should be small  very small. Not more then maybe two days. Even better not more then one day or maybe only a few hours. Ask yourself “Will I have this done by tomorrow?“. If the answer is “No” then you need to slice this story once more and make two out of it. If they still are too big – slice them again – and again.

Slicing stories and making each story smaller and smaller does not only lead to a precise “estimate” but also further clarifies the story. This means we reduce the over-all risk because when we slice it we also clarify the smaller peaces until we can easily handle them in our brain.

Another benefit of slicing is that you’ll get a 50% / 50% option to not implement a slice at all. This is very useful for managing the scope.

Managing the scope

Regarding to Vasco, managing the scope is the only way to fulfil deadlines successfully. Good project-leader/product-owners manage the scope from day 1. Having more but smaller user stories means that you as a PL / PO immediately have more options to manage scope for example by dropping one or another story.

From Ron Jeffrey’s I got the hint to do the stories with the most business value first (if possible). Together with a good DevOps pipeline and fast iterations you’ll push releases to customers very fast and hopefully get feedback fast too. As you go through your user-stories based on busines-values this ensures the right overall direction early in the project. You then can let the customer decide which release he/she likes to take to production. It’s also up to the customer if he wants to spend money for more iterations/sprints to get even more user-stories done. I know – this doesn’t work for each project setup. For example Gov projects don’t work like this even if they say they are agile they are not, never ever.

Offering fixed price projects

Let’s say you’re in the project business and have to offer fix priced projects on a regular basis. Projects of the size of about $200-500k need multiple days of work for estimation. Not counting the work to document them. It also needs the best employees to do it as it is really tricky and require a lot experience. Last but not least you will win only one out of a few projects. This means that this work mostly is done for free. A total waste of time in many cases but you must do offers to get work at some point.

How to do this more efficiently and with no estimates?

Vasco showed a method of building a catalog of your past projects. Create categories – like a taxonomy – for your projects. Categories may vary per company and can be something like “Do they have good specs?”, “Does the customer work in the agile dev team?”, etc. Then categorise the projects you already did and specify the price and the count of persons that worked at the project.

If you have to do a offer just compare the new project to your previous projects using this project catalog. This way you can tell the customer a rough price-tag very quickly. Propose to clarify further details in one (or more) workshops – which, by the way, are then paid.

Conclusion

I feel really inspired by the meet-up and the topic in general. It sounds reasonable to me and fits into what I learned in my 25+ years experience of software development. I definitely will try these things. It’s clear that these ideas don’t work for each project or customer. Especially government and other old-school enterprise organisation.