Welcome!

@DevOpsSummit Authors: Liz McMillan, Yeshim Deniz, Zakia Bouachraoui, Pat Romanski, Elizabeth White

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.


@DevOpsSummit Stories
With more than 30 Kubernetes solutions in the marketplace, it's tempting to think Kubernetes and the vendor ecosystem has solved the problem of operationalizing containers at scale or of automatically managing the elasticity of the underlying infrastructure that these solutions need to be truly scalable. Far from it. There are at least six major pain points that companies experience when they try to deploy and run Kubernetes in their complex environments. In this presentation, the speaker will detail these pain points and explain how cloud can address them.
While DevOps most critically and famously fosters collaboration, communication, and integration through cultural change, culture is more of an output than an input. In order to actively drive cultural evolution, organizations must make substantial organizational and process changes, and adopt new technologies, to encourage a DevOps culture. Moderated by Andi Mann, panelists discussed how to balance these three pillars of DevOps, where to focus attention (and resources), where organizations might slip up with the wrong focus, how to manage change and risk in all three areas, what is possible and what is not, where to start, and especially how new structures, processes, and technologies can help drive a new DevOps culture.
When building large, cloud-based applications that operate at a high scale, it's important to maintain a high availability and resilience to failures. In order to do that, you must be tolerant of failures, even in light of failures in other areas of your application. "Fly two mistakes high" is an old adage in the radio control airplane hobby. It means, fly high enough so that if you make a mistake, you can continue flying with room to still make mistakes. In his session at 18th Cloud Expo, Lee Atchison, Principal Cloud Architect and Advocate at New Relic, discussed how this same philosophy can be applied to highly scaled applications, and can dramatically increase your resilience to failure.
As Cybric's Chief Technology Officer, Mike D. Kail is responsible for the strategic vision and technical direction of the platform. Prior to founding Cybric, Mike was Yahoo's CIO and SVP of Infrastructure, where he led the IT and Data Center functions for the company. He has more than 24 years of IT Operations experience with a focus on highly-scalable architectures.
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regulatory scrutiny and increasing consumer lack of trust in technology in general.