Disciplined Agile Estimation or Guesstimation?

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

  1. DA sizing and estimation options are right for any project, even if it’s not agile.
  2. 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.
  3. 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.
  4. 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.
  5. Team sizing is beneficial, and using ranges or relative estimation techniques has been proven as effective as a modern way of working.
  6. 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.
  7. Realize that reasonable estimates take investments in time and money, even lightweight approaches and agile techniques require due diligence and some expertise
  8. Explore your options and refine your estimation techniques by improving your way of working.
  9. 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.
  10. 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]

Ready to level up your career?

Recent Posts


Born 1965, San Antonio, Texas and lives in Dallas, Tx.
Mr. James, Ronald, Maverick holds a Bachelor of Science in Psychology at The University of Texas, San Antonio.

Mr. Maverick or JR as many call him is a “slick” but warm and friendly character in our upcoming book on the DevOps Mindset. Mr. Maverick cares about his IT team very much and could charm the socks off a Texas Longhorn. JR is liked by many in his organization; however, he is not as well trusted by the Overlords as he used to be. Mr. Maverick has a group of loyal staff, including Mr. Barker a bit of an opposite to JR. Of course, Mr. Barker would never call him JR; he would only call him Mr. Maverick because well, Mr. Maverick is his boss. Mr. Maverick has held many IT positions in the past, including starting as a Sales Professional for HP and IBM mini and mainframe computers. Over the years he has risen through the ranks to hold this senior position by delivering using high-paid consultants and Big name firms. He also received his promotion from outsourcing to a foreign country where he was able to reduce his IT spend significantly. Recently he has discovered (actually this was made painfully aware to him by the Overlords) that both the Offshore roadmap and use of external consultants was not giving him the value and velocity for his IT department, and he was probably paying more than he bargained for

So, after hearing a talk at a DevOps event by the Agents of Chaos, JR decided to enlist them to help with their digital transformation roadmap and help improve the value, focus and velocity of his department. However, MR. Maverick has a few ideas about agile and DevOps, something he has heard about for a while and read in various CIO magazines; he thinks of these as Marketing terms and something that can be bought. While Mr. Maverick has held on for many years to traditional IT ways of working he has come to the end of his tenure if he doesn’t do something fast and get DevOps working quickly as he has promised to the Overlords providing him with a little more rope to get the transformation completed more quickly as they view his IT department ageing, procrastinators who are not able to keep up with business demands. JR says in his mind, “I will get it done, they don’t call me Maverick for nothing!“