Blog
This is how we do estimate a project in agile
You have an idea for a product and you want to build it in a fast manner. Even though you don't have complete clarity of the requirements or scope, you believe you will be able to define them with the help of your technology partner or enabler. You then discuss the product idea with your potential technology partner, and they recommend that you opt for Agile methodology. You then insist on getting a budget estimate without compromising the release date. Sound familiar?
If yes, then you have found yourself in a common conundrum - "the estimation in Agile" which presents you with the fear of exceeding the budget; you will find this article quite useful.
The Purpose and Benefits of Estimation in Agile
Ensuring successful software delivery within the triple constraints i.e. scope, schedule and cost, has been an enigma that every software development methodology has aimed to solve.
These 3 dimensions of scope, cost, and schedule are interdependent. In any scenario, it is possible to make only one of these 3 dimensions constant. For developing software within a certain cost, the scope and schedule will have to be kept variable. Similarly, if the schedule or a deadline is constant, the scope and cost need to be variable. No matter how much we want to, we cannot fix more than one. It would go against the DNA of software development.
Taking a step back: the Iron Triangle (the triple constraints) is a legacy handed down to the software development world by the world that builds cars and buildings - a world where cost, scope, and schedule is based on properties. These could be estimated in detail prior to manufacturing, planning that could further be handed off to the builders - plans that do not change after the assembly process has started.
Software delivery is another world. The requirements or scope keep changing, so the main questions that arise are - How do we estimate the cost and how do we plan for the schedule?
Enter the proponents of Agile methodology, that endorsed the fact that change is at the core of software development; so, rather than fight change, we learn to manage change, almost celebrate it!
Agile methodology at its core uses the technique of breaking down the work into small batch sizes and uses continuous market feedback to guide progress. Unlike the assembly line where the customer does not see the product until the end, in Agile, a small increment of the product is available for a "show and tell" at short intervals. Decisions can be made if the plan is adhered to or if there are course corrections. Build what is needed not what was planned.
The cost involved in this methodology is essentially the cost of the dedicated team that comes together to deliver.
How We Estimate Software Development Projects Within our Agile Framework
In the real world, even though we appreciate the merits of Agile and we embrace the fact that changes will occur, we want to carve out a budget to estimate our spending. When we start a project, we have a limited horizon.
We propose a short discovery phase to overcome this problem.
The discovery phase establishes the essential tenet of Agile methodology that consists of breaking down the requirements into small batch sizes. This is an exercise that takes typically 2-4 weeks, depending upon the complexity of the business's project.
The discovery phase unfolds as follows:
1. Stakeholder Interviews
The Business Analyst (BA) assigned to the discovery team revisits any existing documentation you share initially and extracts the gaps and queries. The BA then conducts regular workshops with the stakeholders to discuss the gaps and clarify doubts in the system workflow. These workshops can be conducted over a call with the client or with client visits to our premises to have one-on-one sessions.
2. Define High-Level Product Backlog
The BA, along with the Technical Architect, frames an initial outcome that the stakeholders are looking for, with a feasible solution or product. A high-level product backlog is defined in terms of epics and story titles, which describe the bare bones of the application. We then validate if the backlog addresses the scope of the project for you.
3. Information Architecture
It is important to understand that UX is equally important aspect of delivery compared to various functional aspects and design. Depending upon the complexity of the problem that the application is intended to solve, a UX anchor is taken onboard, along with the BA, for the discovery phase. The UX Analyst's prime deliverable is to understand not just you, but your customer as well. The UX analyst works on personas of the possible user group who could use the application, the ecosystem in which the personas will be using the application and touchpoints of the user personas with the system. The deliverables here would be ecosystem maps, personas, user journeys, and storyboards. The primary deliverable from the UX Anchor would be to provide complete information architecture for the application giving an overview of the system.
4. Prioritization
The discovery team then works on the high-level backlog, once validated by the stakeholder. An analysis is employed as the prioritization method in order to decide which requirements to complete first, which ones can come later and which ones to exclude. The backlog items are divided into 'must haves,' 'should haves,' 'could haves,' and 'won't have.'
The items with the highest business value and lowest effort involved are often the items that qualify the 'must haves' criteria. The items that are of higher priority and will need some effort to be delivered are deemed, as 'should haves.' All the backlog items that might be desirable in terms of scope but are of lower business value are segmented, as 'could haves.' The items that are agreed upon to be moved to later releases are filtered out as 'won't have' for now.
5. Minimal Viable Product (MVP) Backlog
Based upon the prioritization activity, the BA assembles the requirements as 'must haves' to the backlog and sections it as the requirements for achieving a Minimum Viable Product (MVP). The MVP backlog might also contain a few items from the 'should have' list, making sure that the product is sufficiently competitive in the market.
6. The Estimation
The discovery team estimates the MVP backlog to define the estimated cost and timeline for the first release.
This is followed by build, rinse and repeat until we arrive at an estimate that fits the business needs. This also allows flexibility to load and off-load features as product development starts. Remember, we are committed to endorsing change as we get closer to the horizon.
An Example to Understand Our Agile Estimation Approach Better
A customer (say John) approached us for getting a CRM developed. We have used some hypothetical names in the example below to protect the identity of the individuals involved:
John approached us through our Account Manager. John explained that he ran a startup and was dependent on VC funding for building his product. He listed out a few features he wanted to include in the CRM solution and problems he wanted to solve.
Though his requirements were not precisely defined, he asked for an estimated budget for the tertiary scope he shared with us.
The account manager then pushed this project into our discovery phase, involving the estimation team that was comprised of Mobility team, A technical architect, and a few more people from the UX/BA team. During the discovery phase, our estimation team held regular workshops with John to understand the requirements and define the scope by filling the gaps.
Our team then defined the modules and viable features for the application and a ballpark figure estimate based on the limited scope.
Rather than providing a single figure as a ballpark, our team split the whole scope into parts based on levels and numbers of resource engagement.
The representatives provided a monthly cost projection along with an estimated number of months the development team needed to deliver the first release of the application.
Since cost projections were estimated on a monthly basis, John was able to approach the investors in a more defined and periodical manner. In addition, he was able to evaluate the monthly payments based on the progress of development, instead of paying the entire cost of development all at once.
Summing Up
As Agile has gained lot of popularity for its flexibility, adaptability, and faster time to market for a project, it also continues to be questioned for the lack of estimation possibilities. However, estimation in Agile is not really that complicated anymore.
In fact, estimation is one of the most critical requirements for a business owner who puts their faith in their technology partner. There is no way a technology partner can avoid it. While there are certain approaches involved in Agile estimation, we have one that can be effective in keeping our clients happy and confident in our abilities.
ABOUT THE AUTHOR Hitendra Kumar – Sr. Solution Architect
Entrepreneurial-spirited, pioneering technologist with 18+ years of experience identifying, qualifying, building consensus for, and implementing enabling technologies and enterprise systems that facilitate business processes and strategic objectives. Broad expertise in IT, Automation, Dev Ops, Cloud, Analytics, Ecommerce and Payment system architecture/infrastructure design, full project life cycle management, client/vendor relationship management, and financial/operational management. Ably manage overall productivity, reorganization, and process improvement initiatives.