Welcome!

@DevOpsSummit Authors: Dalibor Siroky, Pat Romanski, Elizabeth White, Liz McMillan, Stackify Blog

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
ChatOps is an emerging topic that has led to the wide availability of integrations between group chat and various other tools/platforms. Currently, HipChat is an extremely powerful collaboration platform due to the various ChatOps integrations that are available. However, DevOps automation can involve orchestration and complex workflows. In his session at @DevOpsSummit at 20th Cloud Expo, Himanshu Chhetri, CTO at Addteq, will cover practical examples and use cases such as self-provisioning infrastructure/applications, self-remediation workflows, integrating monitoring and complimenting integrations between Atlassian tools and other top tools in the industry.
"Storpool does only block-level storage so we do one thing extremely well. The growth in data is what drives the move to software-defined technologies in general and software-defined storage," explained Boyan Ivanov, CEO and co-founder at StorPool, in this SYS-CON.tv interview at 16th Cloud Expo, held June 9-11, 2015, at the Javits Center in New York City.
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, answered these questions and demonstrated techniques for implementing advanced scheduling. For example, using spot instances and cost-effective resources on AWS, coupled with the ability to deliver a minimum set of functionalities that cover the majority of needs – without configuration complexity.
As Marc Andreessen says software is eating the world. Everything is rapidly moving toward being software-defined – from our phones and cars through our washing machines to the datacenter. However, there are larger challenges when implementing software defined on a larger scale - when building software defined infrastructure. In his session at 16th Cloud Expo, Boyan Ivanov, CEO of StorPool, provided some practical insights on what, how and why when implementing "software-defined" in the datacenter.
A strange thing is happening along the way to the Internet of Things, namely far too many devices to work with and manage. It has become clear that we'll need much higher efficiency user experiences that can allow us to more easily and scalably work with the thousands of devices that will soon be in each of our lives. Enter the conversational interface revolution, combining bots we can literally talk with, gesture to, and even direct with our thoughts, with embedded artificial intelligence, which can process our conversational commands and orchestrate the outcomes we request across our personal and professional realm of connected devices.