Welcome!

Recurring Revenue Authors: Liz McMillan, Pat Romanski, Yeshim Deniz, Elizabeth White, Zakia Bouachraoui

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.


IoT & Smart Cities Stories
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Cell networks have the advantage of long-range communications, reaching an estimated 90% of the world. But cell networks such as 2G, 3G and LTE consume lots of power and were designed for connecting people. They are not optimized for low- or battery-powered devices or for IoT applications with infrequently transmitted data. Cell IoT modules that support narrow-band IoT and 4G cell networks will enable cell connectivity, device management, and app enablement for low-power wide-area network IoT. B...
The hierarchical architecture that distributes "compute" within the network specially at the edge can enable new services by harnessing emerging technologies. But Edge-Compute comes at increased cost that needs to be managed and potentially augmented by creative architecture solutions as there will always a catching-up with the capacity demands. Processing power in smartphones has enhanced YoY and there is increasingly spare compute capacity that can be potentially pooled. Uber has successfully ...
SYS-CON Events announced today that CrowdReviews.com has been named “Media Sponsor” of SYS-CON's 22nd International Cloud Expo, which will take place on June 5–7, 2018, at the Javits Center in New York City, NY. CrowdReviews.com is a transparent online platform for determining which products and services are the best based on the opinion of the crowd. The crowd consists of Internet users that have experienced products and services first-hand and have an interest in letting other potential buye...
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...