The nature of Agile software delivery means that the full detail of what's being built can't be known in advance. That can make it challenging to forecast an accurate budget. But as Jon Last, Head of UK Delivery at NashTech explains, there are ways to provide a high degree of budget certainty without compromising project agility or the quality of the end-product.
Every software development project has to balance conflicting demands. The most common are time, cost, features and quality - but attempting to pin down all four at the start of a project is generally unrealistic. It might be possible to do so in a perfect world where business needs never change, everything is clearly understood in advance, and issues never arise - but we don't live in such a world!
Fortunately, most enterprises today realise this, which is why Agile delivery has become the preferred way for development teams to stay responsive to the evolving needs of the business. Agile allows you to embrace the typical challenges faced by the modern digital organisation:
At the same time, Agile promotes Lean Thinking - which discourages expending effort on specifying everything up front. One consequence of that is that the team generally won't generate an estimate that allows creation of a baseline budget.
So how do you forecast an accurate budget when you haven't worked out in detail what you're going to build?
NashTech is experienced at helping customers manage projects to fixed budgets. Our Responsive Offshore Agile Delivery (ROAD) methodology and engagement models provide a higher degree of budget certainty, without compromising the agility of the project or the quality of the end-product. We take the following key steps.
We generally start by facilitating requirements workshops to define an initial set of epics and features. We use a range of techniques (for example, the MoSCoW method of prioritisation) to categorise those epics and features and decide which ones should form part of the minimum viable product (MVP) to meet users' initial and essential needs.
Within the scope of the MVP, we recommend distinguishing between the epics and features that are well defined and understood, and those that are uncertain or harder to understand. This work is critical to determining the potential budget range for the MVP, as complex and hard-to-understand epics will carry a higher degree of uncertainty and so influence an increase in the budget coefficient.
In parallel, we recommend conducting technical workshops to take the requirements and define how the solution will be architected to meet them. This allows us to identify areas of technical risk in the proposed solution, which further informs the budget range.
We then combine what we've learned about the client's specific project with our extensive estimation knowledge base to calculate an estimate range for the effort needed to deliver the MVP. The estimate will be expressed in person days, converted into the number of development sprints of a typical NashTech scrum team.
In addition, we assess the project against a 'cone of uncertainty' based on the maturity of, and the risks associated with:
The number of development sprints is then multiplied by the coefficient from the uncertainty assessment to calculate the minimum and maximum number of sprints, and therefore the cost range to deliver the MVP scope.
We realise, of course, that our clients may want to take different approaches. We'll work with you to agree what 'deliver MVP scope' means from the outset. We'll also provide input and feedback on options and their impact throughout the delivery phase, as your business needs and priorities flex in response to customer requirements.
Our recommendation is that sprint planning should include only the user stories that are 'must haves' for the MVP, and that others are left in the product backlog.
We also suggest planning to deliver functionality that will test the primary concepts and main flows as early as possible, with the aim of identifying and resolving functional and technical risks and uncertainties. Doing this early means there's a good chance of accelerating more straightforward areas, or enabling conversations about reducing scope before it's too late to avoid a wider impact.
Rapid feedback in Agile means a change in priority is readily accepted, with new ideas and requirements easily added. Equally, obsolete concepts can be removed with little or no cost consequence. It's crucial to maintain a ruthless discipline so that only true 'must haves' remain.
Of course, client feedback - through involvement in stand-ups, sprint demonstrations and retrospectives - is vital to catching any misunderstandings and continually refining and optimising the process. We then take evidence of delivery throughput (velocity) to assess the original plan. Actual under- or over-estimations of story point delivery are then used to recalibrate the likely delivery date and cost of the current MVP.
This growing body of empirical data will then form the basis for extrapolating the likely time and cost of the whole requirement backlog.
Managing projects to a budget in Agile brings its own set of challenges. We understand those challenges and have adapted our approach to handle them with an emphasis on dialogue, refinement and iteration - all increasingly informed by actual information as a project progresses.
Our approach produces an initial estimate with a level of confidence based on the information available at initiation, and draws on our empirical historical knowledge. We provide a framework to constantly recalibrate estimates, supporting business decision-making on scope priorities at the earliest opportunity.
To find out how NashTech can help your organisation improve the budget certainty of Agile projects without compromising delivery, visit our software development services or email info@nashtechglobal.com and a member of the team will be in touch.