Software Dev Estimations – The Gift that Keeps on Giving

Over the past 15 years of my career, I’ve noticed that estimations are the most controversial aspect of the Agile software development process.  I can’t count how many times I’ve heard the push back from my developers (or said it myself as a developer): “I don’t have time”, “it’s not accurate”, “don’t hold me accountable”, or “isn’t estimation a waterfall process”.  It may be considered unconventional for my role to be diving into the weeds of detailed software dev processes, however, I’ve recently observed a process change that has greased our development pipeline and has had a huge impact on our broader technology effectiveness.

I believe that once a dev team willfully adopts a technical estimation process into their sprint cadence, it becomes the single most important swim lane within the entire pipeline.  If the right granularity of discussion is occurring at the right time with the right audience, the resulting positive impact is much broader than merely outputting an estimate metric.  It’s all about the journey of getting there. 

First, the Nuts and Bolts:

Before I get into the reasons why I’m such a big proponent, let me first share the nuts and bolts of our process:

Assuming you Already Have...

• Experienced & disciplined Product Manager

• Well-defined business cases for new features/projects
• Prioritized backlog of new features based on business value
• Established Agile software development cadence

Format of Meeting:

Bring together the entire cross-functional scrum team (developers, QA, product managers, analysts, scrum master) once every week for an hour.  The goal is not just estimating Stories in the measurable units of days.  It’s much broader in continually pumping in clearly defined work to the Ready for Development backlog.  Start at the top of the backlog and for each, ask:

• What is this ticket asking for?
• Do we have all use-cases defined (we're starting to use BDD more and more)
• How are 2-3 ways we can implement this request?
• What risks are there to existing code?
• How will we test it?

The results of each estimated ticket should be decomposed work from a potentially complex original ticket, new research tickets for unanswered questions, or moving existing tickets back to analysis. 

The Intangible Benefits of Estimation:

There are not only tangible benefits of the actual estimate metric itself, but additional quick wins that include less overhead of fragmented meetings, just-in-time estimation, and emphasis on further analysis or requirement definition if need be. However, the longer term benefits are the most valuable:

• Enhanced Business Cases & Prioritization

• Well-defined Architecture
• Collaboration & Team Member Inclusion
  
  
  

1.  Enhanced Business Cases & Prioritization:

Companies have finite resources, and often times dev teams are the limiting factor. Thus, prioritization often becomes the deciding factor in whether to take on projects.  Technical estimation allows the company to have better metrics on a true ROI.  It’s not just about raw business value to drive priority, but often sizing is important for sequencing and scoping.  Because the stories going into estimation are already prioritized based on business value, only the most important Stories are estimated and often times, the estimate itself gives business stakeholders true costs and trade-offs on what to include or not include in scope.  It helps make decisions on what NOT to do.

Additionally, technical estimation aligns with the Lean Startup and Continuous Delivery philosophy of developing and deploying a minimal viable product fast and early, and then iterating.  The estimate potentially encourages a negotiation in scope that creates a healthy balance of extent of change, speed to market, and magnitude of resources needed.    

2.  Well-Defined Architecture:

You can’t design software architecture without having well-defined functionality.  Similarly, you can’t estimate technical details without having the architecture defined.  Therefore, if you can get an accurate technical estimate, then you likely have solid/hardened requirements (including wireframes/comps) and architecture defined. 

There have been numerous instances where a discussion in the estimation session sheds light on technical deficiencies such as performance and scalability or working through complex business rules themselves.  As the old adage says: “two minds are better than one, etc, etc”.  The interdependent team members come together and are forced to work through nuances of details, ranging from database CRUD to domain logic to front-end development to performance and functionality testing.  Good estimates require some thinking and decomposition of work, which in turn start flushing out individual tasks.  Furthermore, the technical estimation process provides an architecture group visibility into what’s coming down the pipeline. 

3.  Collaboration & Team Member Inclusion:

Teams that overly rely on just planning poker or other tools to vote on story sizes may miss out on important team dynamics.  Yes, technical estimation is an investment of time, however, it has significant benefits when it comes to team cohesion and collaboration.  Developing an estimate metric is a mechanism for individuals to share their understanding of the requirement(s), ask questions, and discuss complexities with the implementation, collaborating, and often times challenging each other. It requires a cross-functional group of software disciplines to discuss and fully buy in to the development approach. 

It also encourages the larger project team to collaborate and gain visibility of incoming work early so that the dev team is not just order takers to a defined spec, but rather providing bi-directional feedback and input back to the business stakeholders.  For example, feasibility concerns can be raised early on, or conversely alternative approaches that provide additional opportunities can be brought to light.  Developers have a voice when it comes to the “What”.    

Conclusion:

As is with any process adoption, technical estimation isn’t for all dev teams.  It’s important to have extremely strong (and trusting) relationships between your developers and your product management and analyst roles.  On top of that, business partners that are already thinking in terms of a Lean Startup approach along with a development team that is well-versed in Agile software development is key.  You’re still going to get your nay-sayer developers, however, I would suggest you try it out for a few months and soon they will be reaping the rewards of fully flushed out requirements, complete wireframes, an enterprise architectural design, and cohesive and unified dev teams.