Our software team has been doing a lot of R&D work to improve the performance of our product. Of course, the management team would like to know how long it's going to take to improve the performance, and how much improvement we'll get.

I'd like to know (1) if there's any suggested estimation technique when you're estimating the time developers will spend working on items such as performance improvements

Also, if possible, (2) what strategies are useful for estimating the amount of improvement you might be able to get with a given investment

Further background:

Our specific research is on improving application performance such as content load, the perceived speed of transitions within the application and other aspects of the user experience.

From the developers' standpoint, we don't know how much improvement we'll get until we make the improvements, and we don't know how long it will take to make the improvements until we dive deep and come up with all of the different ways we might speed things up.

I've read the basic literature about software estimation techniques (story points, function points, etc), so I don't need a primer on those. We do have at least a good start on gathering baseline performance metrics, and I don't need more info about basic metrics right now.

  • Hi Linda - is your team an already stable team or a relatively new team? Is there openness to speak frankly with senior management? This is key to define how to approach performance improvement.
    – Tiago Cardoso
    Commented Feb 27, 2019 at 7:11
  • We're a mature team, with a reasonably ability to speak frankly with management, yes. Commented Feb 27, 2019 at 13:44
  • Hi Linda - I've restructured the question to make it less specific to your case. Hope the core questions are still kept. Feel free to roll changes back if you're not ok with them.
    – Tiago Cardoso
    Commented Feb 28, 2019 at 18:28

2 Answers 2


Do you keep metrics on earlier refactoring efforts? If not you should. This allows for evidence based estimation; What did we do before? How long did we think it would take? How long did it actually take?

Once you have some data points, you can look at apples to apples comparisons. For stuff you don't have, you can take a look at your estimates vs. actuals to be able to determine how accurate your team is. Even if they are consistently 200% under the actuals, that gives you a pretty good idea that this estimate is also going to be under what it will really take.

% of performance improvements is harder to quantify, but if you are building things correctly the percentage should trend lower as the easy stuff gets optimized.


1) To be able to determine the time it will take, you need to scope what you are going to do. If you have a baseline of the current performance, you must be able to determine the things that need to perform better. If you ask developers they can spend years tweaking and improving the performance. Key is, in my opinion, to define a scope and work towards that. Identify the 'slow' parts and determine how fast it should be, the goal does not have to be reached in 1 go. You could create spikes per discipline (e.g. search, back end, front end) so they can investigate the performance and come up solutions. This has worked for me several times

2) The improvement can only be proven by running the same tests that created the baseline of performance. A developer will always be able to indicate if something will improve performance or not, but not by how much %. Obviously some testing should be done while implementing the improvements to see if they have the desired effect, but unless they are done on a production like environment it will be an indication.

Hope this helps, Bart

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.