Agile Estimation: What Worked for Us!
Take a look at how this team went from sending their clients into a panic to developing an effective Agile system that other teams began to use.
Join the DZone community and get the full member experience.Join For Free
We wish every team had Enrico Fermi. If he could estimate the power of an atomic bomb using little pieces of paper, surely he would be handy during estimation of backlogs!
Estimation has always been a contentious topic in the agile world. The different schools of thoughts and dozens of relative estimation techniques might leave many in a daze.
We were no different! We are a 100 member unit with team members distributed in different parts of the globe. Planning poker worked out well when the scope of the product was limited with a small set of backlogs.
It also served as an icebreaker for all of us, since we had been handpicked from different teams for this product development and dint know each other. But as the product started scaling up with lot more modules (and obviously many more backlogs), the activity started taking a toll on us. We literally felt like Tom in the below meme!
Apart from being time consuming, at the end of each iteration there were complaints of over commitment, scope creep, and fatigue among others. Also we rarely delivered on time, prompting the business owners to push the panic button. So we were tasked with finding out a solution for this.
We went about researching in the net and discussing with fellow agile practitioners. We also collected feedback and suggestions from all team members. Since we were using an agile product to track our delivery, there was enough data in form of reports to supplement our research.
Our findings were quite startling:
Contrary to general perception, our actual vs. estimated reports showed that our estimation was not way off the mark, so we concluded that over commitment was not because of our estimation technique.
Though everyone was actively participating in the estimation process, not many believed in it. They also didn't trust each other’s estimates!
The most popular feedback was to do away with the estimation process completely. The general opinion was that estimates (with story points) are mostly guesses (wild ones!) and was put forth by the team only because of arm twisting by the “big guys” on the business team).
The iteration retrospective was turning out to be a finger pointing exercise without any areas of improvement being identified.
To sum up, the team didn't believe in an elaborate estimation technique.
Scrap the current estimation technique and go for an approach which merely puts the backlogs in buckets. We felt features should be classified into buckets rather than looking for a number. We chose T-shirt sizing since the entire team was comfortable with this.
During estimation merely pick the number of backlogs (with no st(rings)ory points attached), which will be delivered by end of this iteration.
Shorten the iteration cycle from 3 weeks to 2 weeks. This will help ease the estimation process considerably. Guessing also becomes easier!
Conduct a focused workshop in the middle of an iteration to plan for the next iteration. The outcome of this workshop will be a set of prudently estimated backlogs.
Make sure every increment (however small) is shipped to the end user immediately. Fail first, fail fast as they call it! If the user doesn’t find value, scrap the module rather than wasting more effort and time on it ("eliminate waste" as they call it in Lean).
Set up an automation ecosystem to make sure recommendation 4 is possible.
For sprint retrospective we recommended Mike Cohn’s start-stop-continue approach.
Finally ensure the product owners spend considerable time (at least a week) with their teams during execution.
The “big guys” were initially skeptical about the recommendations since they were obsessed with story points and deadlines. Setting up an automation ecosystem meant higher investment in the form of tools. But eventually they did concede some ground by agreeing to implement the recommendations for an iteration for one team. If it works, it would be scaled to other teams.
During the estimation ceremony the team chose 5 backlogs to be completed by the end of the iteration with two of them in the XL category and three in the medium category. Since the teams had “estimated” without any arm twisting, they were pretty confident in completing the set of backlogs. We also cajoled the Product Owner to sit with the team during the first half of the iteration. The team’s confidence was evident during the iteration review meeting. For the first time in years, they had delivered what they had promised! Though the business guys were miffed with the size of the increment, they were relieved that the team finally found some rhythm. This accomplishment boosted the morale of the entire team.
So what did we do different? Nothing much to be honest.
We merely empowered the team and trusted their estimates.
We eliminated story points from the equation. Yes, we consider story points as evil!
We ironed out any differences between the product owner and the other team members by making the PO sit (quite literally!) with the team.
From a technical perspective, we recruited automation experts and set up an automated delivery pipeline. So every time a change was being made, the next minute the build package was in the testing environment. With servers too being managed using code, developers didn't have to wait for environments anymore.
Enthused by this approach’s success, other teams followed suit. Apart from a few cavilling here and there, the delivery was largely smooth without any slippages. A word of caution! Just because this worked for us doesn’t mean this is one size fits all approach.
As we speak we are trying to scale this approach to other portfolios in our organisation. We will be back with more insights and real time data! Meanwhile do let us know what worked for your teams in the comments section!
Opinions expressed by DZone contributors are their own.