The Bucharest Agile Community had a meetup on “Estimation Techniques”. The topic was picked in the spring by the community and was so popular that a second session was required.
The discussion on sprint planning was easier because less risks are involved. Beside the classic planning poker with story points we discussed about a few other techniques:
- Counting stories instead of giving them story points. The general intuition is that it works for stories that are roughly the same size, something teams who master story slicing are able to do. However, data from the #NoEstimates movement shows that it seems to work for more general cases. The debate is still on.
- Bucket estimation. This is the name I gave to a technique I used with a team that was deploying every 2-3 days. The only question we asked was: does this story fit in two days? If it didn’t, we would slice it. If we finished earlier, we would move to the next. The bucket metaphor refers to asking: would this much water fit into this bucket?
- Just do it, without estimating. Again, this method bears the risk of slowing down the team cadence because it doesn’t give feedback on where we are, even in the context of a two week sprint.
In the end, I think it’s worth mentioning a few situations where bad estimates are a symptom and not the problem:
- When the team deals with code they’re afraid to change. Estimating precisely in this context is impossible. A simple task like changing a label could take one hour or five days, depending on how convoluted the code is. I call these items “icebergs” because I have no idea what lies under the surface. This is usually a bad case of technical debt or architectural debt and requires special attention.
- When the team accepts in the sprint requirements that aren’t clear. The team will then need to spend more time understanding the story during the sprint or implement the wrong thing. The Scrum way of solving this issue is the “Definition of Ready”. The Definition of Ready is a clear contract between the team and the Product Owner that defines what criteria should a story have in order to be accepted in sprint. A rule of thumb would be: don’t accept stories where you still have questions about “what we’re doing”; technical questions (“how we’ll do it”) can usually be solved during a sprint.
- When requirements change during the sprint. While change is part of the agile mindset, it’s a fact of life that change takes time. The reason we try to understand what needs to be done before the sprint is to focus on implementation during the sprint; changing requirements often means the time spent on understanding and implementing the story until that point was a waste. It’s also a fact of life that sometimes change is inevitable; the most important thing is to be mindful about the kind of changes introduced in a sprint.
Many thanks to Ubervu for hosting this meetup, and to Mihai Oprea for his support.
Troubles with estimation? We can help with:
- An assessment on your organizational practices
- Calling one of our coaches in for facilitating a release planning
- Attending the “User Stories for Agile Requirements” workshop, also available in-company
- Attending the “Agile Development using Scrum” workshop, also available in-company
Is technical debt a problem? Try:
- An assessment on your code or architecture
- Pair program with one of our coaches on refactoring legacy code
- Attend the “Working FAST and Safe with Existing Code” workshop, also available in-company
If the situation is more complex, we would be happy to create a customized package for your needs.