Various articles on SCRUM methodology explicitly state that sizing should not fo
ID: 639081 • Letter: V
Question
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.
Explanation / Answer
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.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.