Having experienced multiple 're-build' projects in my career, I know that it is hard to capture all of the requirements from the working software. Often because of the size of the code base and lack of documentation. To the client, it seems clear what is required - that is all of the features from their existing project with an upgrade / change of framework and infrastructure.

In each case, either an estimate has been performed and failed to capture all of the required features, or the estimating process has been deemed too expensive to do thoroughly. And so the business (questionably) decides to use Agile / Scrum methodologies to complete the project.

This in effect means we have waterfall-esqe project in that it has fixed requirements, but an acceptance that we're going to have to work it out as we go along, in an imperfect 'Agile' manner.

This leads to a high probability of either project time / budget overruns or an unhappy client who percieves that the new software lacks capability that was present in the previous version.

Specifically, the question is: How do you estimate (in terms of time and cost) for a 're-build' where you are rebuilding an existing piece of software, and can agile be used?

I'm anticipating the following answers, but would like to hear from anyone who has experience of a process that has worked.

  • Is the answer simply that you don't? Maybe the business has to accept that software that has evolved over years will be expensive to replace. How does a business make a decision whether the project is worth undertaking?

  • Is the answer that the business has to agree to undertake the project in an agile manner, and monitor progress regularly to help them to decide whether to continue?

  • Is the answer that the estimate should be undertaken and paid for as a project in it's self. You would then be tasked with estimating how long you need to produce a good estimate? Understanding a project properly could take an amount of effort not far short of implementing in code.

Related reading I've done before posting this question:

  • 1
    Why do you need to rebuild something that already works? Things you should never do, part 1. Agile would probably say start from the already working software and, over time, make it more similar to how you want it to be! Dec 9, 2022 at 18:07
  • agile estimations are complexity points, not time points. If you need to know time, I'm not sure agile is the best approach. Developers get constantly told not to estimate in time in agile, and any mention of time is usually frowned upon. Dec 9, 2022 at 19:34
  • Thanks for the link @user253751, it was also recommended to me elsewhere and I think it's a great article. To answer your question on why, in two previous cases it was because of obsolescence of the framework used, and the UI was very out of date by consumer application standards. In the second case it was to move away from an Oracle system that was costing too much to run and proving difficult to extend and maintain. In the last and current project that prompted the question, it's to move away from a consultancy provided solution to common, (very big) company wide infrastructure.
    – gbro3n
    Dec 11, 2022 at 20:36

4 Answers 4



You have an X/Y problem. You have a client that can't or won't expend the time, effort, or cost needed to define the work, but wants a fixed price. You're trying to solve for "how can we provide a fixed price for fixed requirements within an agile framework," but your real problem is that you have too many unknown unknowns to do this. Either address that head-on, or you and the client must both accept the risk that the project is likely to fail.

Analysis and Recommendations


[E]ither an estimate has been performed and failed to capture all of the required features, or the estimating process has been deemed too expensive to do thoroughly...[so the project] has fixed requirements[.]

To paraphrase, you have a legacy system. No one has a full set of specifications, understands the whole system, or is able to maintain it. They want a work-alike, but can't or won't define what that actually means.

This isn't really a "rebuild." It is essentially a feature-by-feature port to a new system, which may include new technologies, languages, hardware, infrastructure, and any number of other things. Even if you had a complete list of specifications for the functional and non-functional aspects of the legacy system (which you don't) you would be hard-pressed to estimate this fundamentally new work on anything other than a time-and-materials basis.

Agile frameworks like Scrum are based on incremental and iterative development leading to emergent design and/or implementation. So, there's no reason you can't use an agile approach, but you and the client must both accept a priori that you are building a new system to implement poorly defined business rules that support existing processes rather than simply swapping out black box components.

Let's set aside whether or not the existing rules and processes should change as part of this effort. If I were in charge, that's where I would start, rather than simply trying to re-implement a legacy system. That's me, though; if the customer is not open to doing things better then you have to address the fact that this amounts to building a new work-alike rather than a "rebuild" or a "re-implementation."


First, have this conversation with your leadership, and let them have it with the client. The pros and cons of any approach and a clear definition of success are must-haves before you fully engage, and the only way to get there is through communication.

Secondly, push for a multi-phase engagement where the first part is a deep-dive assessment. This is likely to involve:

  1. Interviewing users to find out what the system does for them and how they use it.
  2. Putting the existing system under test in some way, even if it's just high-level behavioral tests with Cucumber or the like.
  3. Clearly define the contractual presumption that without some form of system testing to define a Definition of Done or "seams" in the system (Working Effectively with Legacy Code. Feathers, Michael. Pearson, 2004.) you cannot guarantee a specific or successful result.
  4. Design a first phase of the project where the deliverable is simply a scope and specification document. It doesn't matter if this is a set of specification documents or an agile Product Backlog; the point is you need inputs that will feed work breakdowns and project planning for follow-on phases either way.
  5. Define the second phase as planning for the third phase. You may or may not be able to roll that into the first or third phase, depending on whether you're doing waterfall or agile, but "planning the plan" in some degree is needed either way.

In the third phase, you either have a complete set of specifications and OKRs to work from, or you build the system using just-in-time planning and just-enough architecture and engineering processes to build the system in small-but-measurable increments that you can inspect and adapt collaboratively with the client.

Pros and Cons

If you take the agile approach, the client gets frequent chances to inspect the work in progress and fine-tune the requirements, implementation details, and the Definition of Done. This doesn't guarantee them a successful project, but it allows them to avoid cost overruns, sunk costs, and deliverables that are not fit for purpose by terminating the project early (thereby saving money) if it isn't going to succeed or is already sufficient even if not necessarily 100% complete.

Because agile projects are based on what is essentially a fixed periodic run-rate of unknown total length, they can also choose to extend the project if they like the results, but it's taking longer than expected. That's the whole point of Sprints, Planning Increments, or whatever your framework uses: it's an inspect-and-adapt opportunity to determine the net present value of the expended costs, and to estimate (not guarantee) the remaining costs to get to "satisfactory" or "good enough" rather than 100% complete.

On the other hand, all-or-nothing approaches can be viable, but lead to someone eating the costs if the project is bases on faulty assumptions, invalid estimates, or anything unexpected and not part of the original plan. This leads to change orders, cost overruns, or deliverables that aren't fit for purpose. It also leads to contractual arguments, which are rarely constructive and largely the domain of the legal departments, and if you get there then the project is pretty much a failure whether you ultimately deliver the thing or not.

The Manifesto for Agile Software Development explicitly values:

Customer collaboration over contract negotiation[.]

for precisely this reason. A hands-off customer that can't or won't collaborate with you to define the work upfront or throughout the course of development is essentially asking you to either accept all the risk, or is forcing you to present a contract with so many explicit assumptions, stipulations, and strategic exit clauses that no one will be happy. It's essentially a document that expects failure, and in this case the likelihood of failure is much greater than the industry average of 68%.

If they aren't going to be collaborative, and both the legacy system and new system are both poorly defined, then both parties are essentially buying a pig in a poke. This is more than just a bad idea. It's pretty much a planned failure where everyone involved can expect failure after sunk costs, unpaid work, death marches, and unmet expectations. And then the legal fun begins!

The Iron Triangle or Quadrangle

The theorem stipulates that you can't fix all aspects of a project at the same time. Anytime you tweak an aspect such as:

  1. Scope
  2. Budget
  3. Schedule
  4. Quality

you impact the others. At least one of these elements must always be flexible. Most agile frameworks prioritize adjustable scope, but other frameworks make different trade-offs.

If you offer a fixed-price, fixed-scope, fixed-schedule contract, then quality and fitness for purpose is the element most likely to suffer. And of course, if you haven't stipulated the trade-offs, you're back to contractual and legal wrangling.

No one wants to have these conversations, but not having them is worse. Part of running any successful project requires making the process as transparent as possible, which means that someone has to be courageous enough to initiate honest conversations about what's required for the project to be successful, not just for one party or the other to buy a pig in a poke.

Changing Your Process Improves the Chances of Success

Think of this as a teachable moment for both your company and the client. By changing the way your company approaches projects like these, regardless of the project management framework used, you can better serve your clients and allow them to make better business decisions as well.

The framework doesn't matter. It's the effectiveness of communications, transparency, and setting of expectations that will set the tone for the project. Those three things are also what make the project more or less likely to succeed.

  • 2
    Thank you. Lots of great answers on this page but yours clarifies the problem well and offers tangible strategies for managing and references to back them up. I like the term 'work-alike' over rebuild and I think "multi phase engagements" are a very sensible approach to this type of project.
    – gbro3n
    Dec 11, 2022 at 20:29

There seems to be two questions here.

The method that you use to estimate a software rebuild effort is no different than the methods that you use to estimate a new software build effort. If and how you estimate will depend on the methods used to perform the effort. Using an approach that tends closer to agile methods will lead to different approaches for estimating, planning, and monitoring the work than using an approach that tends closer to plan-driven methods.

Agile methods are a viable option for performing a software rebuild. In fact, I would even go as far as to say that they are preferred. When rebuilding an existing system, an initial thought may be to try to totally reproduce the existing system using newer technologies or in a newer environment. However, this begins to break down. Consider that some functionality in the existing system may not be necessary and there may be savings in eliminating support for those features. If you're changing technology, consider that there may be alternative user interaction paradigms that can improve the user experience that could be experimented with. A "lift-and-shift" approach may not be the right one.

If you do decide to go with an agile approach to rebuilding, you are saying that the requirements are uncertain and may evolve as you build the system. I would suggest skipping estimation. The rebuild has some value to the stakeholders. How much are they willing to bet to see if they can get that value? Does that bet allow you to fund a whole team for some time to jump in, start doing the work, get feedback, and build historical data regarding their performance to forecast future work (along with timelines and budgets)? If so, do that. As you go, you can keep stakeholders up-to-date on costs while focusing on building the right thing. Once you've demonstrated the ability to deliver value, the stakeholders can continue to fund the effort until it no longer makes sense to do so.

If you decide that the full set of requirements is necessary and likely to be static, there are plenty of estimation techniques that can be used. There are whole books on software estimation with tips and methods to decompose the work and do the best you can. Of course, you'll also need to build in change control for when the requirements do change or you learn something that you didn't know up-front.

The software development organization usually isn't in a place to tell the stakeholders how to make decisions about what projects are worth it. The best the development organization can do it give options for building the software and find ways to reduce the risk the stakeholders are taking on. My experience tells me that agile methods with regularly stakeholder feedback are the best ways to manage risks associated with system functionality, budgets, and schedules.

  • 1
    IME this doesn't work. If your system is, say, a system to fill out tax forms--then you need to fill out all the tax forms before the users will use it. If you try to tell them to fill out some forms in system A and some in system B then they will probably revolt (not to mention you may not be able to properly fill out the forms anyway, if the forms are reliant on data that goes across forms). Requirements to upgrade systems are often coming from the top of the organization down, as in "we no longer want to pay for the mainframe, all software on the mainframe must be re-written". Dec 8, 2022 at 19:36
  • And "full set of requirements" is just a joke. The full set of requirements is that the new software must fill all the functionality that the old software had, but better and faster. You can try leaving off some stuff that seems to be not used, but then you find out that it was only used by one group during the end-of-year accounting and it's absolutely critical during that time or something. Dec 8, 2022 at 19:40
  • 2
    @user3067860 I never said that you could go live and fully replace the old system in a couple of iterations. Building iteratively and incrementally would let you get feedback from key stakeholders. At some point, the stakeholders will either terminate the effort or they will say that they can start using the new system. Perhaps they will use both systems in parallel, for different groups of people, even. But what I've described is a good way to replace a legacy system.
    – Thomas Owens
    Dec 8, 2022 at 19:58
  • We did that. What happened was that even though the new system was up running in parallel as it was built out feature by feature no one used the new system until the legacy system was shut off (after 6 years! spent developing the new system) and then they suddenly had a lot of problems they "found" in the new system. Dec 8, 2022 at 20:53
  • And we're also currently doing this with a different system and management is angry with the technical teams since everyone keeps finding features in the legacy system that need to be added to the new system which of course pushes out the completion date (and features get released and then have to be turned off/rolled back since some important thing was missed, etc.). Dec 8, 2022 at 20:57

Setting out with the intention of replicating something that already exists is arguably not the best way to deliver value or get support from business stakeholders. It's often that sort of thing that makes users sceptical about the value of technology.

The better approach is indeed to partner with business, understand what they like and dislike about the current product(s), allow business stakeholders to identify the priorities to fix or change and then deliver that value incrementally. Software can evolve continuously as new priorities come to the top of the list so there's no absolute need to have an end in sight.

Long-term estimation is generally easier if you take an agile approach. Firstly because estimating short cadences of independent delivery is easier than mapping out lots of dependencies over the long-term. Secondly because agility emphasises adaptability and an evidence-based approach. If you are delivering business value regularly and being responsive to customer needs then stakeholders will likely be more understanding of changes in direction and schedule.

  • What if the part that they don't like is that it's running on a mainframe and the business is getting rid of the mainframe? (Or that it's only running on Windows 95 or that it's only running in IE or that the whole thing is just extremely slow which is limited by the underlying architecture?) Dec 8, 2022 at 19:42
  • 1
    @user3067860 If it's only running on something that is being gotten rid of, it may be possible to run it on a VM of that thing. That is if the problem is the hardware. If it's because it can only run on Win 95 and that's been unsupported for years, that's a different matter.
    – nasch
    Dec 9, 2022 at 0:36
  • 1
    @nasch also if it only runs on Win95, you may start by identifying the reasons why it can only run on Win95 and fixing those, and now that you have Win95-looking software that runs on Windows 11, identify where to go next. Only running on win95 is certainly no reason to rewrite the whole piece of software. Dec 9, 2022 at 18:06
  • @user253751 I agree, but it could be an obstacle to just virtualizing it. I'm in agreement with Joel that rewriting is seldom the right answer.
    – nasch
    Dec 9, 2022 at 22:48

How do you estimate (in terms of time and cost) for a 're-build' where you are rebuilding an existing piece of software, and can agile be used?

A lot will depend on your software architecture and your domain.

For example, the answer would likely change based on:

  • Is the software to be replaced broken down into components that can be replaced incrementally?
  • How difficult will it be to parallel run the new software alongside the existing software?
  • Are you expecting to replace the code like-for-like, or will you be making improvements at the same time as rewriting it?

Depending on the answers to these questions, my preferred approach would be to:

  • Identify and document the functionality of the existing system (including business rules embedded in the code).
  • Create automated test coverage on the existing system that validates the documented functionality.
  • Work in an agile fashion to incrementally swap out components of the existing system with new code, while using the test coverage to ensure that the functionality remains as expected.

This allows us to follow an agile approach, measuring progress with real working software and allowing us to adapt to unexpected change (such as technical issues).

Estimation will then be based on real progress. For example, you can formulate initial estimates and then update them as and when each component of the original software has been replaced. This empirical feedback will give the team confidence that their estimates will get more accurate the longer the project goes on.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.