Last year, I referred to a quote from the TV show ‘Better Call Saul’ in a blog, https://dzone.com/articles/perfection-is-the-enemy-of-perfectly-adequate-a-le to draw a parallel to building MVPs.

We have a new season out this year, and keeping it topical, here I am using another one of the quotes from the show as uttered by the iconic character Chuck McGill. 

Often when we start developing new features/products in a typical agile fashion, software development teams don’t have everything thought out. Instead, based on historical data, certain approximations are made and when needed, a proof-of-concept is also designed and developed to help plan the necessary work.

One of these approximations is the ‘confidence’ to determine a timeline for the delivery of this product.

What are we deducing from it?

1. Right away, the level of confidence is an indicator of where we are on the ‘pessimistic to optimistic’ spectrum
2. What assumptions are made to determine the confidence level
3. What the existing unknowns are
4. Overall team enthusiasm at the beginning stage of software development – this is always good to acknowledge :)

As we all know, no software development process is smooth and free of wrinkles. The initial estimation almost always isn’t accurate, and therefore development teams take in a buffer before this timeline is communicated to product management teams and other stakeholders. Confidence might help assess the delivery timelines more accurately, but facts are key to helping us efficiently plan these and manage our customer expectations.

Here are some of the ‘facts’ that can really help us out with ironing out this process

Metrics

There is a variety of metrics that can be identified and measured throughout the software development process that are essentially a manifestation of facts.

 ADRs (Architecture Decision Record) 

ADR in general is a good practice to document that captures the context of a problem statement and the decisions taken while outlining the pros and cons of the considered solutions. These really help especially when a complex design/re-design is being proposed. ADRs are usually a result of a spike or a proof-of-concept done by SMEs or dev leads. 

Team Velocity

In agile development, velocity is the measure of the number of user stories completed by a team in a sprint. Over time, this metric is a good tool for estimation and helps greatly in forecasting the projected completion date based on the capacity of the team and historical progress on feature development. There are also various reports such as cumulative flow diagrams or release burndowns that can help monitor the projected release dates. The caveat of such measurements is the accuracy of tracked data and the agile maturity of the teams. 

Cycle Time for Stories

To get more granular, you can also measure the historical cycle time for a story using your project management tool that gives time from its ideation to availability in production. 

A simple wireframe of a basic workflow looks like this

If each step of the process is measured in the tool, the time for lead time can be easily calculated, in addition to also calculating bottlenecks in the process.

DORA 

DevOps Research and Assessment (DORA) metrics are extremely useful for analyzing the quality and performance of software development CI/CD pipelines. Measuring deployment frequency, lead time to change, change failure rate, and time to restore service, give a well-rounded insight into how fast the features can be delivered to customers.

Trusted Advice

The best source to get a realistic estimate is the team. The word of developers is quite valuable in painting a realistic picture. One could argue that this depends on the variety of software being developed, but if we rely on the discretion of the developers along with a measure of historical data, we will become more efficient. This also establishes a good degree of trust between management, product, and the development teams. 

The quote pretty much makes up for the punchline. Confidence is good, facts on your side, are better. Let’s all get out there and build software with speed, and more importantly, efficiently.