Share with Friends
In my lunch and learn session this week for one of my clients, I covered an important topic on practical lessons and ways to improve our estimates.
Many organizations and their IT departments have difficulty sizing and estimating their projects or product during the “intake” or project initiation phase. Using Disciplined Agile in your practice supports seven fundamental principles that include excellent scoping and release planning goals. With the DA “Inception” phase, there are baked-in process goals with useful and modern sizing and estimation options.
In my presentation, I cover this topic by referring to Scott Ambler’s two factual articles and blogs. One (of many) articles he wrote on Dr. Dobbs Journal is called “Lies, Great lies & Software Development Project Plans” and this is just as relevant today as it was in 2009. The other excellent reference is from his blog on DisciplinedAgileDelivery.com Lies, Great lies & Software Development Project Plans by Scott Amber, Co-Founder of Disciplined Agile.
I shall summarize some key points from both Scott’s articles and my experience as well.
[divider height=”30″ style=”default” line=”default” color=”” themecolor=”0″]
Estimation is just hard!
If estimation were easy to predict, we would be probably in a perfect world. Thus many of our organizations are “complex adaptive systems” and IT is not the greatest at communicating with internal and external stakeholders. Many departments work in silos and may have poor feedback loops with each other at the best of times, below are a few reasons why we find estimation challenging to get right.
- IT complexity, such as moving targets, many variables
- IT resisting change because many times it’s difficult to change
- Poor relationships with their internal and external stakeholders
- Stakeholders across the organization including shareholders, want to reduce risk thus want IT projects to be a precise and “guaranteed” success
- Without reliable and fast communication, stable IT, i.e. predictable and controllable change it’s challenging thus a lack of feedback loops to drivers of change is missing
- People in general, take estimates as contracts and already have unrealistic expectations
We can do better!
Measure success in small batches, and size in teams
- DA sizing and estimation options are right for any project, even if it’s not agile.
- Agile projects when using DA and selecting good practices (a term used in our (goal->decision->option toolkit) such as working in small batches and using knowledgable, same teams will make better estimates. This approach is considered “lightweight” sizing and estimation.
- Use any calculation, estimate technique, black magic, or just rolling the dice, when proven as evidence shows; that in reality, we see that initial estimation techniques fall short of predicting with a reasonable amount accuracy. The number is usually within an average somewhere around 11% accuracy.
- Sizing and estimation are not the same things, for example, software sizing is different from software effort estimation. Sizing estimates the probable size of a piece of software while effort estimation predicts the effort needed to build it. The relationship between the size of software and the effort required to produce it is called productivity.
- Team sizing is beneficial, and using ranges or relative estimation techniques has been proven as effective as a modern way of working.
- Estimations are just approximations, so regular and consistent feedback with your stakeholders when working in small batches with agile projects makes for better stakeholder management and expectations. Think of communicating and demoing often to raise awareness and elicit feedback that can accelerate your whole process.
- Realize that reasonable estimates take investments in time and money, even lightweight approaches and agile techniques require due diligence and some expertise
- Explore your options and refine your estimation techniques by improving your way of working.
- Practice with your team’s sizing and estimation techniques using exercises such as estimation games or through additional education and training, unlocking new skills and honing existing ones.
- Look at sizing and estimation from a “top-down” approach, which means less detail to incrementally build your product rather than the waterfall “bottom-up” approach. This avoids gathering large sets of requirements based on everchanging understanding and requirements because we know that what was perceived of value today will likely change tomorrow.
This DA Goal & choose Estimation Unit Decision is key to making your WoW Work!
I would love to hear your thoughts, so please comment below or send us an email, [email protected].
