Beyond estimates: building an information stack for risk - Part one

During her talk, Stop Asking Me How Long It Will Take, at PyCon Italia 2026 in Bologna, Ines Panker made a point that has stayed with us: when we ask for an estimate, we may not simply be asking how long the work will take. What we really want is to reduce the risk involved in making a decision.

Estimates still have a role to play. They help organisations assess an investment, compare options, allocate capacity and align expectations. But a number on its own says nothing about the quality of the information behind it. It does not expose the assumptions on which it depends, the external factors that could invalidate it, or how quickly the team will be able to establish whether the work is delivering value.

The answer, in our view, is not to stop estimating. It is to place estimates within a broader information stack: assumptions, confidence levels, dependencies, decisions, historical delivery data and signals collected as the work progresses. Engineering practices are part of that stack too: peer review, shared ownership, constructive challenge and the ability to surface unknowns before they become costly.

Risk management then becomes less about producing an increasingly precise number and more about building a system that learns. Estimates remain one input, but they no longer carry the full weight of the decision. The system makes uncertainty visible and manageable while creating opportunities to validate value early.

In this article, we examine what this looks like in practice through cases, methods and progressively more structured solutions drawn from Nephila’s day-to-day engineering work.

Software estimation, as Ines explains, is an inherently unreliable forecasting exercise. Developers are expected to provide precise figures while working in environments where requirements and specifications continue to evolve. This remains true even for mature teams with decades of experience. We know estimates tend to be optimistic, yet clients and organisations continue to favour apparently exact numbers, even when those numbers repeatedly prove wrong.

The reason is that the real purpose of an estimate is not accuracy. It is to reduce perceived uncertainty and make project risk easier to reason about.

The more useful shift, Ines suggests, is therefore away from long-range estimation and towards the active management of risk, expectations and changing requirements. In a high-variability environment, software delivery is better understood as a process of continuous discovery than as an end-to-end process whose cost and duration can be predicted in advance.

The following insights from the talk spoke most directly to the realities our teams face when estimating software—and to the practices and experiments we have developed in response.

One pattern we see repeatedly in engineering teams—and one widely reflected in both research and industry experience—is that estimation is affected not only by the technical complexity of the work, but also by cognitive bias. Some people underestimate through overconfidence or oversimplification; others add excessive contingency as a precaution. Risk is also perceived differently depending on a person’s role, and that inevitably influences the estimate they produce.

For stable teams with strong domain knowledge, we use a well-established peer-review process. Each work item is analysed and estimated by the person best placed to do so, based on their technical expertise, delivery experience and knowledge of the project’s history. A second team member then reviews both the analysis and the estimate.

This allows us to draw on individual expertise without leaving the outcome dependent on one person’s assumptions. A second perspective can expose blind spots, challenge the proposed implementation and test the reasoning behind the estimate. The same process applies to everyone, regardless of seniority—including software architects and the CTO.

One example comes from the long-term maintenance and evolution of a Django platform used by a public-sector organisation to manage university scholarships and student grants. We inherited a complex architecture and now work with the client’s team to maintain it, extend it and improve its resilience over time.

Each work item is assigned to the engineer—or one of the engineers—with the strongest knowledge of the part of the system it affects. That person documents the analysis and assigns an estimate using T-shirt sizing. The estimate also provides a consistent input for capacity allocation during planning.

Another engineer with relevant expertise then reviews the analysis and estimate. They may validate the outcome, request clarification, challenge specific assumptions or ask for the work to be reassessed. Could the reviewer redo the analysis and estimate from scratch? In principle, yes. It happens rarely, but the process allows for it. The objective is not to defend the first answer. It is to produce a technically sound analysis and an estimate that remains coherent with the wider system and its architectural constraints.

Planning Poker is particularly useful when knowledge is distributed across the team, levels of expertise and seniority vary, or there is no historical baseline to draw on—all conditions that leave more room for cognitive bias. Each team member estimates independently, often using the Fibonacci sequence, and the group focuses its discussion on the estimates that diverge most until it arrives at an agreed estimate.

We used this approach while developing part of the point-of-sale client interface for a colour-matching system built for one of the world’s largest paint manufacturers. The solution allowed users to find, customise and dispense colour formulations while exchanging data with a remote server.

It was a relatively large team, made up mainly of frontend and full-stack developers. Using Planning Poker at task level helped people move beyond the fear of getting the estimate “wrong”. It also built a shared understanding across the wider delivery group, including project managers, account managers and team leads.

We had a relatively large team, made up mainly of frontend and full-stack developers. Using Planning Poker at task level helped engineers move beyond the fear of getting an estimate “wrong”. It also created a shared understanding of the work across the wider delivery group, including project managers, account managers and team leads.

Risk was contained first and foremost by breaking down the tasks brought into planning, reducing their technical complexity as far as possible. This meant that the main remaining area of risk was cognitive bias. The pluralistic nature of Planning Poker, combined with the statistical value of drawing on multiple independent estimates, helped narrow the confidence gap. When estimates were furthest apart, the discussion focused on the analytical reasoning behind them, allowing the team to arrive at an agreed estimate.

Over time, we built up a set of measurable reference stories. These became working benchmarks, steadily improving the team’s ability to forecast future work.

Engineering teams produce estimates continuously, but many organisations fail to close the feedback loop between estimated and actual effort. Estimates are captured during planning; delivery data is collected elsewhere, if at all; and the two are rarely compared at work-item level.

Without that comparison, teams cannot calibrate future estimates against historical delivery data. Estimation remains a one-off forecasting exercise rather than an evolving capability informed by evidence.

In an agile environment, actual effort should not be used to assess individual performance or assign blame when estimates prove inaccurate. Its purpose is to help the team understand where assumptions failed, which dependencies emerged during delivery, and how scope, complexity or context changed after planning. That evidence can then be used to adjust capacity, refine reference stories and improve future forecasts.

We adopted the first part of this principle quite strictly. Our retrospectives focused on what had gone wrong and why, prioritising delivery context over a systematic comparison of estimated and actual effort.

At the same time, Nephila is a data-informed organisation. Time is our primary capacity constraint, and we analyse how it is allocated to understand how the wider delivery system is operating and where we need to adjust course. Our people work across several client projects, internal applications and digital products—some of them publicly released—as well as the development of engineering methods and practices. We also reserve a significant allocation for research, professional development and community work.

Mapping how capacity is used serves both an analytical and an organisational-design purpose. It allows us to balance the competing objectives of a diverse portfolio of work involving the whole company and to recalibrate priorities through weekly internal sprints.

This visibility is important, for example, when balancing individual workloads. We try to avoid assigning an engineer to more than two or three projects within the same sprint. Beyond that point, context switching begins to fragment attention, affecting both engineering quality and individual wellbeing.

All our work, including activities not directly related to digital product development, is represented as user stories and managed in Taiga, a Django-based project management platform. Every work item created in Taiga is fed into our custom Django-based time-tracking system, where each person records the effort spent on it.

Because we designed and built the applications behind this data pipeline, we can extend the same model to client projects delivered through collaborative engineering, even when the client uses a different project management platform. API integrations bring work-item data from the client’s environment into our time-tracking system, eliminating the need for engineers to record the same activity twice.

This is particularly valuable when development work must be formally reported. The integration reduces administrative overhead, preserves work-item-level detail and removes the transcription errors introduced by manual data transfer between systems.

We have taken this approach a step further with a long-standing client that publishes several academic journals. It is a highly collaborative environment in which we share expertise in Django, software architecture, product management and delivery methods. Much of the work centres on extending Janeway, an open-source platform for publishing academic research online. The integrated team also contributes its work back to the Janeway open-source project.

In this case, the two organisations operate as an integrated engineering team, with roles and responsibilities distributed across both sides and developers from each organisation contributing to delivery. One of our software architects leads planning and holds technical responsibility for the development stream, guiding the team’s estimates through T-shirt sizing.

The client manages its work in GitLab, which is connected to our time-tracking system through APIs. Actual effort recorded by the Nephila engineers in the integrated team is linked back to individual work items. This creates a growing dataset that can be compared with the original estimates, giving the integrated team an evidence base for calibrating reference stories and improving its forecasting capability over time.

***

This is the first of two parts of Beyond Estimates: Building an Information Stack for Risk Management. Part Two will be published on 24 September and will conclude the discussion with two further cases: estimation from the client’s perspective, with its focus on time and cost, and the challenges of estimating complex, scalable projects.

***

We wrote this article with the support of AI. If you’re interested in how we use these tools as part of our writing process, you can read more here.

Cover image:
Photo by Ximena Balderas su Unsplash