How can I do L1, L2, and L3 effort estimation for Applications Support? I am naive and don't have any experience. Can anyone tell me, from very basic fundamentals, with an example? It will be great help.

  • Hi Sanchit, what do you mean by "Applications Support"? You mean the kind of routine work a team needs to do for an application that's already live and in production? – Tiago Cardoso Oct 7 '18 at 18:32
  • Yeah it's daily routine work team does to give support to application users. Its not related to development at all. Its about already application in production state and user use it and while using it they face any issues/problem then to resolve that they log tickets with service desk. – Sanchit Kumar Oct 8 '18 at 19:12

In theory, estimates for support activities are easier to provide for a single reason: historic evidences.

Working myself with PROD support for years, I know that some tasks are unpredictable, and that's part of the game. But it's also true that some support activities are similar to already solved issues. The key is to identify these patterns.

So, back to the original question: how to estimate application support actions?

  • Identify patterns. It's like a puzzle (and can be as entertaining as such!). You have to group support tasks into buckets. You start with two buckets, the "common"/"already occurred" and the "new"/"I have no idea what's this about" issues (like the borders and insiders of a puzzle).
  • Dig a bit further into the common tasks. Creating a map where people could understand where the problem is could be helpful. Accept you won't be able to estimate all issues from scratch.
  • Define very high level complexity level for the common tasks. Nothing too hard to swallow, just measure the complexity in "high / med / low" (relative to each other) or any other measure the team prefers. It's key to have the team onboarded, otherwise just forget about the whole stuff.
  • Evaluate how long each of them takes in average. Average is key. Remember not the same person will be dealing with the same problem (and if that's the case, your project is at risk).

Rinse and repeat.

As your team evolves, more patterns will be identified and better estimates, provided.

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.