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?

  • Agile estimates should be based on effort, not complexity. See mountaingoatsoftware.com/blog/its-effort-not-complexity and mountaingoatsoftware.com/blog/… for more directly from Mike Cohn. – Todd A. Jacobs Aug 7 '19 at 16:55
  • Is effort not considered for estimation? I thought that was the first thing to consider. Take example of verifying records in two excel sheet. For 10 records, I probably won't even bother estimating. For 10 million records, I am going to consider 1 week at least, and some time to research automation options. – jitendragarg Aug 22 '19 at 10:22
  • Also, I would suggest prioritizing stories with low complexity and high effort for your automation plan. If a story like this is regular, then it should get automated as soon as possible. If it is just one time, I will consider automation during the sprint planning and estimate effort accordingly. – jitendragarg Aug 22 '19 at 10:40

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.

| improve this answer | |

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.