How to handle requirements with an unclear scope containing words «all», «everywhere», etc.?

Question

Let's say, customer or product owner creates a task that looks like this:

Change localization Old term to New term in all places in the app for language X.

And development team needs to provide an estimate for this. But there is no person in the team who knows the codebase well enough to get a list of all occurrences. The project is just too big and exists for several years already.

We can assume that we only change localization file(s) for language X, but what if somebody accidentally hard-coded localization somewhere (and this is totally possible for the concrete project)... Additionally, Old term may be a part of several other bigger sentences in localization sources spread within the whole app!

What should we do in such a situation:

• ask the customer/PO for the list of concrete screens in the application (sure there will be some discussion and misunderstanding), or
• provide an estimate that includes the full reverse engineering process, which will be pretty big, and lead to additional, maybe pretty long, discussion about this?

It's important to mention that the estimate should be more or less committable and the task itself is pretty small if we would have a concretely defined scope.

P.S.: do not focus on the concrete example details, here are a couple more examples to better describe the overall situation:

Change the color of all green buttons to red on all website pages.

Closing animation for every expandable component (drop-down, spoiler, "show more", etc.) must have a duration of exactly N ms.

Answer 1

Negotiate.

Speak with whomever came up with the requirement. Explain the situation and the challenges involved. It may be the outcome is a change in the definition of the requirement, or perhaps they will agree that an investigation needs to be done first to come up with a more reliable estimate.

All requirements should be negotiable. This is important when you want to follow an agile approach and collaborate.

It is also why the INVEST mnemonic includes N for negotiable.

Answer 2

Interesting question.

For me, I'd plan the work this way:

0. Communicate to the change requestor that changes that aren't fully specified will result in a plan that has a wider range of estimates. (aside: this is sophistry; all plans are estimates based on ranges. values in a plan, unmodified by a range are known by the technical project management term "fiction"; honest plans are based on an estimate and a range around that estimate. The more vague the specification of the task, the wider the range of estimate)

1. Catalog the instances of 'old term' in the existing code base. Start with a simple search of the code base, but store the answer in an agreed upon repository. (this should be a task that is relatively simple to estimate, based on the understanding that the first draft of the catalog will be no more than 80% accurate )

2. Estimate the time to change all instances of 'old term' to 'new term' based on the catalog.

3. Carry out the update based on the estimate in 2.

4. As a normal part of "buffing the backlog" (you don't specify scrum, so I'm using the term loosely - no matter your methodology, there is some list of work that is "in the backlog"), update the catalog of 'old term'. This should also be part of code maintenance - when you are working a bug and find an instance of 'old term', update the catalog. When you have an idle moment and you can't face the prospect of another customer centered task, take a stab at updating the catalog. When you've got a junior/new staff member who needs a task that will help them to be familiar with the code base, update the catalog. If the catalog changes in size significantly, update the estimate in 2.

5. Why doesn't your codebase already contain a cross referenced list of functions/terms/variables/entrypoints? Add to the backlog the effort required to expand the catalog to a full index of your codebase. This investment will pay off in speeding future changes, reducing bug diagnosis, better estimates etc.

Answer 3

Before the team estimates this, there's some refinement to be done. Someone, perhaps multiple people, from the team should take the time to understand and investigate this work to see what the scope is. They can identify the specific sections of the system that need to be updated and make a note of them. The refinement and identification of impacted parts of the system can help the team to estimate the work. This investigation may also find ways to split up the work in a way that makes sense to incrementally deliver.

In some cases, the change may be extremely urgent. In that case, it may be worth the risk of just doing the work until its done. It may not be worth estimating the work, but just starting to do it. However, there's always the risk that something unexpected happens and the work is not complete. If that's an acceptable risk, then additional changes can be done as follow-up work later on after the initial delivery.

Answer 4

There are two ways to do it, right;

1. Make a discovery to find every piece of code that needs to be changed and add them to the task
2. Go blindly and try to do it

Estimate which one will take less time and communicate your recommendation with the customer according to the customer's priority; efforts vs. quality of the output. For example, "If we make the discovery, the efforts will be too high. Let's start doing the changes without discovery; it will cost less. But, if we miss some parts, we will find them in production and try to fix them ASAP."

Answer 5

The definition of "all" is actually quite clear and explicit. Worse offenders are: "proper", "good quality", "too high". They are middle ground, with no numerical / measurable reference.

So when you receive a request with "all", you should do the following (together with your team).

1. Do an automatic search in all the work products to find "all" occurrences of the relevant word (e.g. "term", red, green button...) and make a clear list. Do not forget to search all word forms, just to be safe. Hopefully you do the job using some proper tools. If your information is in pictures-of-used-whiteboards, then I wish you a very warm good luck.
2. Group them based on the how clear it is for you to handle them. Example: shall-modify, maybe-modify, do-not-modify, we-have-no-idea.
3. Present the list to the customer, to give their approval.
4. Clarify all the details with the customer, make decisions together.
5. Implement the decisions.
6. After the job is finished, if the customer finds problems not identified initially, handle each request one by one.

That is basic project management, and basic requirements engineering.

Answer 6

Pick some subset of "all" which you can sensibly estimate, create a new story for it and prioritise that story before the rest. Hopefully doing the work on the reduced scope will give the team a better insight into the larger piece of work.

Alternatively, since you say the task is "pretty small" if the scope is known, maybe it is small enough that you can just take a calculated risk that it could be done in one iteration and see how far the team can get. The important thing is not the estimate, but the degree of confidence the team has that it can be completed in a single iteration.