Welcome!

Machine Learning Authors: Yeshim Deniz, Liz McMillan, Elizabeth White, Pat Romanski, Corey Roth

Related Topics: @DevOpsSummit

@DevOpsSummit: Blog Post

Is There Value in Estimating Software Delivery Times? | @DevOpsSummit #CD #APM #Monitoring

Software development may not be magic, but it is completely veiled in the abstract

I often hear software development referred to as "magic." Those of us who are software engineers may scoff at this, but it reveals the outside world's perception of what we do. Software development may not be magic, but it is completely veiled in the abstract, and therefore difficult for the uninitiated to understand.

This misconception underscores the difficulties of those outside the software engineering team who rely heavily on the output from this ‘magic' (or in other words, ‘the product'). Project managers, product owners, sales, et al., need to provide delivery times to customers, but have no means of calculating these times beyond asking the software engineers for an estimated completion time. And herein lies the crux of the issue.

Different values
Task estimation is a controversial subject in software. Although some engineers debate the values of estimation models vs. expert judgment - using complicated formulas vs. relying on your senior engineer's gut instincts - the majority of us question if there is any value in estimations at all. Why spend time calculating estimates that are nearly always wrong? There are many reasons for inaccuracies, including scope changes, engineer's optimism and a simple misunderstanding of the problem. So is there any value in estimates?

For any member of the software development and delivery value stream that is not a software engineer, the answer is an unequivocal "yes" because:

  • Estimations are often the only recognized tool in providing delivery dates.
  • For teams such as marketing, documentation and operations, these delivery dates are keys for prioritizing and timing their work.
  • Anyone interacting directly with customers relies heavily on delivery dates when closing deals.

The answer to this question is less obvious for software engineers. Not only does spending effort on these estimations delay us from working on the solution, but often the estimates provide false information. Why not simply prioritize the work, and let engineers get back to engineering?

Case in point
I manage a software team at Tasktop. For a number of years, the team provided estimates at the epic level. The team would perform a rough preliminary breakdown of the epic into user stories that would be refined later. With this preliminary breakdown, user stories were discussed among the team engineers, and then estimated as story points using planning or Scrum poker.

The story points were then rolled up into the epic, producing an estimate, which were compared to prior completed epic estimates, and actual completion times, to calculate the expected output. Using these estimates, product owners were able to provide their customers with expected timelines. These dates were not always met, but customers seemed to understand this and allowed for some reasonable variance. As long as most features were delivered on time, a few misses could be absorbed.

A change in process
A little over a year ago, we decided to change our development process from Scrum to Kanban. This change was done to improve the team's focus. With Kanban, we stopped wasting time in meetings, and were able to adjust our priorities much more quickly. But without our artificial sprint boundaries, we started worrying a lot less about estimates. Since we no longer needed to estimate how much work could be completed in a sprint, we just let the priority define what we would work on, and completed the work as quickly as we could. Since we could not work any faster, and we were always working on the most important tasks, what was the value of the estimate?

An erosion of trust
As it turns out, the value of the estimate was measured in the trust that our team had with the product owners. Without estimates, the product owners were not able to predict when features would be completed and struggled to communicate this to customers. At the same time, engineers soon became frustrated with the product owners constantly checking in to see when a feature would be ready.

Product owners also found it more difficult to prioritize the work without the estimated cost of completion. Theoretically, the priority of a feature should be based solely on the customer value but, realistically, completing three "high" priority features in the same time as one "very high" priority feature may bring more overall customer value to the company.

All of this leads to an erosion of trust between product owners and engineers. Despite both departments trying to do their best to support the other, the communication gap widened, people became frustrated, and productivity slowed.

Finding common ground
These issues were identified by both departments during release retrospective meetings. It was proposed that the engineers add estimation back into the process with a renewed effort into improving their quality.

The engineers, although reluctant to start estimating again, understood that a change was needed. Our prior estimation process was enhanced with epic retrospectives, which focused on the quality of estimations. At the completion of each epic, the story estimations were reviewed and compared with the actual effort. This created a mindful feedback loop, stimulating thoughtful discussions and helping to identify and improve our most common mistakes.

As soon as the estimations were added back into the process, trust returned. Reasonable timelines could be established and the features could be better prioritized. When the estimates were wrong, there was a basis for measuring this and discussing what went wrong and how to improve. Product owners felt more confidence in the timelines being provided to customers, and engineers were once again left alone to complete their work.

While estimates continue to frustrate us with their lack of precise accuracy, the answer turns out to be: yes, there is real value in estimating software delivery times - even to software engineers.

More Stories By Colin Ritchie

Colin Ritchie is an Engineering Manager at Tasktop Technologies. He has been writing software since the late 1980s on a Commodore 64. A graduate of the University of British Columbia, he has worked across a range of senior and management roles across the software development spectrum in a number of different sectors.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


CloudEXPO Stories
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the massive amount of information associated with these devices. Ed presented sought out sessions at CloudEXPO Silicon Valley 2017 and CloudEXPO New York 2017. He is a regular contributor to Cloud Computing Journal.
DXWorldEXPO LLC announced today that Kevin Jackson joined the faculty of CloudEXPO's "10-Year Anniversary Event" which will take place on November 11-13, 2018 in New York City. Kevin L. Jackson is a globally recognized cloud computing expert and Founder/Author of the award winning "Cloud Musings" blog. Mr. Jackson has also been recognized as a "Top 100 Cybersecurity Influencer and Brand" by Onalytica (2015), a Huffington Post "Top 100 Cloud Computing Experts on Twitter" (2013) and a "Top 50 Cloud Computing Blogger for IT Integrators" by CRN (2015). Mr. Jackson's professional career includes service in the US Navy Space Systems Command, Vice President J.P. Morgan Chase, Worldwide Sales Executive for IBM and NJVC Vice President, Cloud Services. He is currently part of a team responsible for onboarding mission applications to the US Intelligence Community cloud computing environment (IC ...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
When applications are hosted on servers, they produce immense quantities of logging data. Quality engineers should verify that apps are producing log data that is existent, correct, consumable, and complete. Otherwise, apps in production are not easily monitored, have issues that are difficult to detect, and cannot be corrected quickly. Tom Chavez presents the four steps that quality engineers should include in every test plan for apps that produce log output or other machine data. Learn the steps so your team's apps not only function but also can be monitored and understood from their machine data when running in production.
To Really Work for Enterprises, MultiCloud Adoption Requires Far Better and Inclusive Cloud Monitoring and Cost Management … But How? Overwhelmingly, even as enterprises have adopted cloud computing and are expanding to multi-cloud computing, IT leaders remain concerned about how to monitor, manage and control costs across hybrid and multi-cloud deployments. It’s clear that traditional IT monitoring and management approaches, designed after all for on-premises data centers, are falling short in this new hybrid and dynamic environment.