Typical question I get is this: is it okay to put tasks on stories?
Answer: yes … caveat: just so to understand the story better.
Followed by another question: ‘can we put hours to a task?’
Answer: yes … caveat: just so to know how many hours is required to complete a task… and not how many hours a team can actually complete a task.
Example: how long is an NBA game? An NBA game is 4 quarters of 12 minutes each, for a total of 48 minutes.
However, regulation time is stopped for many aspects of gameplay, like fouls, ball out-of-bounds, timeouts, and a 15-minute halftime. That makes the wall-clock duration of typical games2-2.5 hours. I’ve seen double overtime as well… taking this longer… to say 3 hours!
Likewise is true to tasks in software development. Example, assume everything is in ideal state, an ‘ABC’ task should complete in 2 hours, but … things happen in the process (delays, unforeseen dependencies, etc) … the team took 8 hours to complete the task!
But… get this…in Scrum, we don’t estimate effort and capacity in absolute terms (using time like hours)… it is unrealistic (remember the basketball of 48 minutes long?)… things happen! Instead, we estimate effort and capacity in relative terms using points — a unit less thingy to gauge the effort (of an executing entity) based on complexity, volume, knowns (e.g. what we know now and from experiences of similar efforts from the past), and unknowns (of which we seek to narrow down as we move forward with what it is we are trying to do or build).
Good thing is this: in Scrum, just like football, rugby, and basketball (to name a few great games for simile), teams are assessed by meeting goals (outcomes) … not how many hours they take to meet the goal. Scrum is result oriented not process oriented.
