Welcome!

@DevOpsSummit Authors: Yeshim Deniz, Zakia Bouachraoui, Carmen Gonzalez, Elizabeth White, Courtney Abud

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
Cloud-Native thinking and Serverless Computing are now the norm in financial services, manufacturing, telco, healthcare, transportation, energy, media, entertainment, retail and other consumer industries, as well as the public sector. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time to wait for long development cycles that produce software that is obsolete at launch. DevOps may be disruptive, but it is essential. DevOpsSUMMIT at CloudEXPO expands the DevOps community, enable a wide sharing of knowledge, and educate delegates and technology providers alike.
Cloud-Native thinking and Serverless Computing are now the norm in financial services, manufacturing, telco, healthcare, transportation, energy, media, entertainment, retail and other consumer industries, as well as the public sector. The widespread success of cloud computing is driving the DevOps revolution in enterprise IT. Now as never before, development teams must communicate and collaborate in a dynamic, 24/7/365 environment. There is no time to wait for long development cycles that produce software that is obsolete at launch. DevOps may be disruptive, but it is essential. DevOpsSUMMIT at CloudEXPO expands the DevOps community, enable a wide sharing of knowledge, and educate delegates and technology providers alike.
The dream is universal: heuristic driven, global business operations without interruption so that nobody has to wake up at 4am to solve a problem. Building upon Nutanix Acropolis software defined storage, virtualization, and networking platform, Mark will demonstrate business lifecycle automation with freedom of choice and consumption models. Hybrid cloud applications and operations are controllable by the Nutanix Prism control plane with Calm automation, which can weave together the following: database as a service with Era, micro segmentation with Flow, event driven lifecycle operations with Epoch monitoring, and both financial and cloud governance with Beam. Combined together, the Nutanix Enterprise Cloud OS democratizes and accelerates every aspect of your business with simplicity, security, and scalability.
Is your enterprise growing the right skills to fight the digital transformation (DX) battles? With 69% of enterprises describing the DX skill drought as being soft skills, rather than technology skills, are you ready to survive against disrupters? The next wave of business disruption is already crashing on your enterprise as AI, Blockchain and IoT change the nature and location of business. Now is the time to prepare. Drawing on experiences with large and midsize enterprises, Marco Coulter tabulates the skills needed to survive DX while innovating at scale. He will start with a focus on the ‘lingua franca' or common language between business and technology needed for today's digitally savvy or agile enterprise.
Where many organizations get into trouble, however, is that they try to have a broad and deep knowledge in each of these areas. This is a huge blow to an organization's productivity. By automating or outsourcing some of these pieces, such as databases, infrastructure, and networks, your team can instead focus on development, testing, and deployment. Further, organizations that focus their attention on these areas can eventually move to a test-driven development structure that condenses several long phases into a faster, more efficient process. This methodology has a name, of course: Continuous delivery. As Jones pointed out at CloudEXPO, continuous delivery allows developers to trim the fat off tasks and gives them more time to focus on the individual parts of the process. But remember-implementing this methodology requires organizations to offload management of databases, infrastruct...