My managers are asking, before green-lighting a new project, how much people (resources) will it take after the project is done, to maintain it. Ie: fix bugs, deploy new features on demand, adapt to changing business processes, etc.?

What I am able to evaluate (based on history of other projects) is avg. number of bugs happening in production. But I don't see how I can evaluate processes changes, new management requests, new business opportunities.

What scrum metrics can I use to calculate this. Or is there any rule-of-thumbs I can rely on?

  • “Maintenance” is not a project, and as such is usually off topic here. The service delivery domain (e.g. ITIL) is more in line with your question than project management, but you probably won’t get the simple, predictive answer you’re looking for from that knowledge domain either. – Todd A. Jacobs Sep 29 '19 at 2:33

There is just no way you could estimate how many people you need to "deploy new features on demand" or "adapt to changing business processes".

That's like saying "please tell us how many people we need to run our business". How would you know?

What you could do is draw from real world examples. Did you have a business change in another system? Could you estimate that for the new system. If so, make a comparison, prepare a report that says "for this change in the past, we needed X people and Y time, if we'd have to make the same change in the new system, we'd probably need Z people and T time. This is better by pp% because of reasons.

But there is no way you can possibly predict how many business changes management wants to have or lawmakers in your country dictate.

| improve this answer | |

Rather than trying to predict the maintenance needs, perhaps it would be a better idea to offer a capacity.

For example, something like:

We will make available a Scrum team of 7 people for 3 months. This team will give us the capacity to deal with 2 major production bugs and to add one new feature (of the equivalent size as the advanced search function) per month.

The management team can then evaluate that capacity and decide if it seems sufficient to meet their expectations.

| improve this answer | |
  • 2
    Offering an initial capacity seems like the only sensible option without a useful baseline. – Todd A. Jacobs Sep 29 '19 at 2:35

Software Maintenance cost survey results

Here is a review of a book:

One of these foundational studies in software maintenance, one of the most widely referenced, was done by a team at UCLA led by Benet P. Lientz and E. Burton Swanson back in the late 1970s. They surveyed software maintenance practices at 487 companies

  • Corrective Maintenance (bug fixes): 21.7%
  • Adaptive Maintenance (keeping up with changes in the environment): 23.6%
  • Perfective Maintenance (new functional or nonfunctional requirements): 51.3%
  • Other: 3.4%

the biggest, most important problems that organizations faced were management problems, not technical problems: trying to find ways to manage escalating customer demands for enhancements and extensions to software.

Given that "managing escalating customer demands" is the largest item, try to negotiate with the customer (even if it is an internal customer) to set expectations and based on that you can arrive at maintenance staffing needs.

| improve this answer | |
  • How does this answer the question? Can you clarify what those numbers would mean in the context of the question asked? – nvoigt Sep 27 '19 at 5:08
  • @nvoigt The OP should put more effort on ways to "manage escalating customer demands". In other words negotiate with the customer (even if it is an internal customer) to set expectations and based on that arrive at maintenance staffing needs. – Ashok Ramachandran Sep 27 '19 at 6:01
  • 1
    Could you edit that into your answer? Maybe including a word on how to report this to their manager? – nvoigt Sep 27 '19 at 6:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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