Wednesday night, 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. This post is about the first part of the meetup.
15 people, including about four newcomers, discussed about estimations in two contexts: before the project starts (release planning) and during the project (sprint planning). The discussions were lively, most of the attendees contributing with their own experience and asking questions.
The discussion on the release planning quickly moved around a list of typical problems with estimating in early stages:
- Risks. In the beginning of the project we know too little about it. The highest risk we are facing is thinking we know more than we do and deriving the estimation based on this flawed assumption. Common risks that influence estimates in this early stage are: use of new, buggy or immature technologies, unclear specifications and existing code (legacy systems).
- Estimates become commitments and costs. This is a risk especially when the estimators (usually developers) are completely disconnected from the commercials.
- Trying to analyze too much. To give a better estimate, we need to understand the requirements better. Usually this requires analysis. But analysis delays the start of the project and can prove very costly. Therefore, a balance needs to be found in terms of precision of the estimate.
The simplest way to deal with these problems is to avoid estimating. When the client can define a budget and a clear target for that budget, the team can start delivering the first features as soon as they are clear enough. Everybody wins: the client because it gets features faster and the team because they skip unpleasant conversations. This requires however a mature team and trust between the customer and the team.
When the customer needs estimates at this point in time, my experience shows that it’s worth being very honest about the risks. The excel file I was using to estimate projects back in my outsourcing days contained for each use case the estimate, the risk level (low, medium, high), a risk correction factor for the estimate (30% for medium risk and 50% or more for high risk) and a list of risks. Making the risks visible helped transforming a conversation on the numbers (why does it take you 10 days to do task X?) into a conversation about risks (oh, actually we can simplify that high risk task and do this instead).
We also repeated one thing everyone should do when estimating at this point in time: never give an estimate as a number, but as a range. Estimation is not an exact science; people can understand that it might take you 1-3 days to do a task, depending on multiple factors.
Techniques discussed included: T-Shirt sizes, planning poker with story points and not estimating at all. I personally found the last technique particularly useful when working with startups during the discovery process. A counter argument was that not estimating makes it harder to derive costs and that it might affect the cadence of the team. This shows once again that each technique works within a specific context; changing the context requires choosing a technique that works.
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.
