The big difference between agile methods and other methods is that you focus more on value and results before time and deadline. The word focus does not mean that time is an unnecessary factor, it is but agile is more about using it effectively in an agile manner.
Many of us that are really passionate about the agile methodology, have actually succeeded with good results in our projects. And our customers have been extremely satisfied and in return we got good relations.
Our highest priority as agile coachers and team is to satisfy the customer through early and continuous delivery of valuable software.
We welcome changing requirements, even late in the development phase. The agile process yields change to the customer’s competitiveness and give us as team leaders or developer the creativity to do good.
We want to deliver working software usually with the timeframe of few week sprints or within few months. Together with the team we want to create good design and code to get out as much of the customer’s requirements as possible, based on requirements with the highest ROI (Return Of Investment) value. And deliver it all within the client’s budget and desired time frames.
We know that business people and developers must work together daily throughout the project. We also like continuous meetings to synchronise with customer continuously. We are simply motivated to deliver high value to the customer together with the customer. And we remove unnecessary management works to visual instead. Therefore, we must constantly work to reduce factors in our own process that does not give teams and customers a good ROI. That is what Agile is all about. As agile team we also know that our time costs money and we need to use it effectively and profitable. We use product owners and agile coachers to remind us.
Heres where #NoEstimate comes in as one of many factors to decrease waste in our projects. #NoEstimate does not mean we should stop estimating, we shall. #NoEstimate focus is to make it right to bring out the best value for both the customer and the team. In Part 1, I talked about the Chaos report that more or less says that about 78% of our estimates are wrong. And therefore classic estimates are waste of time in our process and can instead be used for other things. Like delivering value to the customer, right? So why not use it to deliver more value to the customer instead? We can never trust our estimates, they are truly lying for us.
Let me give you some more examples.
You estimate with planning poker or something similar to get as close estimates as possible right?
There is a problem with planning poker. Say that a team set an user story with the number 13. What does that mean? 13h? (2.1 days?). A space of time against Another User Story? 13 as in 13 days? The higher the number is, the harder it is to get the correct estimate. Higher numbers are higher risks. The higher it is the more complex it is. If we want to trust the Chaos report, then 13 user story point has 78% chance of being wrong. It even has a chance (if it is a medium sized company) to go 220% over the time.
That mean that a 13 user story point can result in about 30 instead. If 13 is a estimate number for days it’s 78% chance that such a point would take 30 days (a month, it is more than a full sprint if you have four weeks sprints.). Imagine then if our project has 10 x 13-day points then it is 78% chance that our 130 days user stories instead will take about 290 days.
(Remember there is also statistics that say that the more experienced you are as a team the better you will hit the right time. But how many elite teams do we have in today’s society? We must constantly replenish with new people so we will never be able to have 100% elite team. That is how our reality looks and the reality we have to adapt.)
Another problem is also the negotiations on the requirements during the project. The customer wants a new requirement but would not extend the deadline. So we negotiate away less important requirement for this new requirement. But how? We do this by estimates the new requirements with Planning Poker and get the number 8. But what does it mean? Normally replace another 8, right?. But is an 8 equal another 8? What if the 8 we will replace actually happened to be one of the 25% chances you have to spot the right estimate and the new 8 happen to be one of the 78% that we gets wrong. There is therefore a risk that the new 8 takes about 18 days and the one you removed actually took 8 days to finish. So it’s 10 days overtime instead. It can also be the other way around, but less likely.
Why do we expose ourselves to this risks when we know about this? Why spend unnecessary time to estimates like this instead of use it to focus on delivery on time instead? In next part (part 3), I will describe some #NoEstimate ideas that will provide safer time estimation and much more measurable velocity quality and ROI for the team and customer.