Estimation in an Agile methodology is a prediction of how soon a certain task, project or a product would be accomplished. A proper estimation might be hard, but it is necessary to give an approximate timeline to the product owner. Teams often struggle with this part of Agile – often quoting ‘we don’t do estimation in Agile’. This isn’t helpful for most stakeholders and only serves to fuel an anti-Agile movement. Estimation is a real-world duty. Estimation can come in several forms, the most common of which are the two questions: How much will it cost? How long will it take? Estimation isn’t just a problem for Agile methodologies – it’s a problem for any software project. You can greatly reduce estimation complexity by simply exploring the constraints you face. Ian Carroll first coined this technique as Constraint Driven Estimation. Explore and capture the key constraints. Is there is there a hard deadline or soft deadline? Is there a fixed budget or cap? If not, then how much are you willing to spend to solve the problem? In other words, what’s your business case for doing this work? Another constraint could be what’s your team capacity and work backwards from that. How many people can you get under the bonnet at the same time? This will have an influence on the overall options you have for answering the cost and time questions. Once you understand your constraints you can then look to shape your scope accordingly. When estimating at the team level, teams often adopt the planning poker technique. Whilst this is a good tool for generating valuable conversation it also results in wasted time and inaccuracy. A more valuable method for estimation is relative sizing. As humans, we’re very poor at saying how big something is, but we’re extremely good at evaluating when something is bigger than something else. Use this technique for estimation. To learn more about simplifying your software estimation, join our one day Lean Agile Boot Camp.

I would like to speak with an advisor