The problem with estimating
Estimation is one of the holy grails of software development. Imagine if you could tell your customer exactly when something is done and how much it will cost…no more deadlines, no more surprises. That would be something, right?
But the world is not perfect, it’s complex. So estimation is hard. And when you work on something risky and challenging, which is hard to estimate, your customer probably wants to have accurate estimates even more!
Agile estimation has been around for a long time, XP and Scrum have brought us story points, velocity and (with the help of some project managers) project burn-downs.
Two years ago, my team was doing Scrum estimation by the book (I still don’t know which one though). The backlog was estimated for months ahead estimation and velocity was tracked as if our life depended on it. As in many teams, this didn’t work quite the way it was advertised. Planning meetings were tough, estimates (in points) often way off, pressure was mounting and code was rushed at the end of the sprints to reach the velocity the team committed to. No, if you have any experience in Agile, you’ll probably find a few mistakes in there.
So we want estimates, but they are hard to get right. We’ve had some interesting experience with estimation ourselves.
We decided to stop estimating. First we needed to get the quality right, the process stable and the testing to be synchronized with coding. So we decided to reduce estimation to a bare minimum. Since we started we went through the following levels of estimation:
- Full fledge Scrum Estimation and Tracking ™
- No estimation, just keep working until the MMF was done (an MMF is something the user can see, touch, taste or smell)
- Estimate the size of the MMF
- Try to keep the MMF size within 2 weeks
We’ve been stuck at 4 for quite a while, using a continuous development process. MMFs are not always the same size though, some can’t be reduced to two weeks and others are just not estimated correctly. There are two reasons I want to get back to a higher level of estimation and tracking:
- Visualize what the team achieves in a given period, much like we track our product performance in the field; you want to know if you’re improving.
- Give the stakeholders some idea when to expect which MMF in the coming months.
These two goals are different, the target is different, one is the team, the other is the stakeholders. I’m hoping to find a minimum viable tracking system that can serve both goals.
Wanting to track the work done and have some (rough) prediction of what we will deliver in the coming months is our goal. Let’s see how to achieve that.
The state of estimation
So, to get back at (team) estimation after disbanding it for 3 years should be interesting. A quick search shows me a mixed bag of the current state of Agile estimation. Three years ago, estimation was non optional. Everyone was doing Scrum (or waterfall) and estimates and velocity were the best things since sliced bread. Today, the situation has changed, with probably many people sharing the same experience we had (estimation sucks). So there seems to be two main approaches to estimation these days:
- Use very little estimating and focus on fast delivery
- Do estimation all the time
Examples for the first (little estimation) often stem from the Kanban arena. Some suggest just counting bite size stories. The stories are roughly the same size, so you can just count how many you’re doing each time period. Predicting far ahead into the future is not possible (and not a goal).
Scrum.org has removed velocity and story points from the guide, but the act of estimation is mentioned and still a key attribute of Scrum. How you estimate, it doesn’t say. Joel Semeniuk gives a good overview of how to tackle estimation.
Try, inspect, improve, repeat
We’ll give estimates another go. The mean principles I think should apply:
- Estimate on a high level
- Separate size estimation from measuring time spent
- Track predication accuracy
Expect another blog post as we learn more about reintroducing estimating. If only I could tell you when I will write it 😉