Various articles on SCRUM methodology explicitly state that sizing should not focus on time, bur rather on the more abstract "complexity" or "effort needed" of the task.

How should a task be sized if the task is trivial to do, but requires a really long time to complete (say, half the sprint or the whole sprint)? Should it be sized 1, 2, 3, or more like 20-40-Inf?

As an example of such a task, I can give the following:

Convert the translated texts from the technical PDF documentation (10 000+ texts) in the correct translations format for Android and iOS.

  • 3
    usually a long tedious task should be automated – jk. Jan 29 '15 at 12:43
  • Agreed. However, what if it can't really be automated (e.g. the PDF example above with a really broken PDF)? – Shade Jan 29 '15 at 12:45

Take any trivial manual task and repeat it 10,000 times.

That will take effort - possibly a lot of effort.

Our profession is all about automation, so the obvious first approach should be "can I automate this?". If you can, you probably should.

However, sometimes you can't automate as much as you'd like - maybe there's no budget for it, maybe defining the rules for automation are too difficult, etc.

It might be quicker to just do the task manually than to automate it.

I see no problem with sizing the task to reflect the work put in - even if it's totally mindless work.


explicitly state that sizing should not focus on time,

They've explicitly stated something ambiguous, "should not focus". Like a lot of agile principles, that doesn't mean never. The point of avoiding focusing on time is because it is difficult. Thinking in time can involve too much precision. If your sprint involved many complex tasks, generally, you should cut back on some.

In this case, it sounds like you have a very good idea of how long this is going to take. That's common with simple tasks. How many boards can you cut in a n hour if it takes 2 minutes to cut each board? You can convert your task into a percentage of the time of your sprint. Everything else gets the rest of the percentage.


When faced with similar tasks in the past what I have done is created a new task(s) to address the issue in a new way. One that better fits the scrum methodology and time frames.

In a situation similar to your example I have a task that comes at the end of every release cycle for translation of new strings in 6 different languages. Sometimes the strings numbers in the thousands. I created a system to extract these strings and format them in an appropriate way making it easier for translations so I had smaller tasks for creation of this tool. Then we have two very small tasks to ensure the strings are exported (sent off for translation by a service) and re-imported using this tool before release.

For many such mundane long tasks I would look at the problem differently and see if it can be automated in part or whole so that it is less time consuming in the future. I have often found that many times it just comes down to thinking about the issue in a different light, recasting the problem and then solving it.

  • Thank you for the answer, but it doesn't answer the question directly. Could you share your thoughts on the situation where neither automating nor splitting/re-thinking the task is possible? – Shade Jan 29 '15 at 15:57

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.