How are low ambiguity and low complexity tickets dealt with when they have a high work cost?

Question

In our scrum team, we can often get user stories which are not very complex and not ambiguous but have a high amount of leg work associated.

Example: We receive a user story to replace the name of a client on 100+ pages. A lot of manual work is required for this but the process of finding the content and updating is very straightforward but requires a good amount of time to complete, say 6 hours.

Because the complexity and ambiguity of the task are low we estimate it as low, but the cost of time is still a factor and effectively a day of work has been taken out.

I'm trying to rationalize in my mind how this would still work when it comes to the velocity at the end of the sprint, reasonably this could cause a reduction in velocity due to the low estimation but no less work would have been completed.

Is there a better way to handle these sorts of stories?

Answer 1

Estimates should be based on effort.

Complexity tends to increase the effort needed.

Ambiguity serves to widen the cone of uncertainty of an estimate, which correspondingly increases the estimate because when providing a single-value estimate, you generally want to be estimating on the upper side of the cone.

But at the end of the day, estimates are estimates of effort.

Low complexity means the base effort won't increase much. Low ambiguity means that you can be confident in your estimation of the effort. But the base effort of the task is high, so the estimate should be high.

Decrease effort if possible

That being said, consider alternate solutions. For your example, why not write a program or a regex to find and replace all instances of the client's name?

Doing so would increase the complexity, but could end up substantially decreasing the base effort, and therefore the estimate. e.g. Instead of taking 6 hours of drudge work, it instead takes 1-4 hours of programming.