When tasks are first put into an Agile backlog (the to-do list), they’re usually kept quite vague to avoid the work of defining the specifics until those specifics need further defining. This works as long as the time estimate for the task is within a reasonable ballpark of what it’ll take when broken down, and that comes with a combination of experience and relying on past estimates to determine future estimates – in other words, it’s fine to be off, as long as you tend to be off the same way all the time.
A good example we’ll encounter with tomorrow’s episode (Episode 19) is the, until now, vague “Scorpion Gameplay” task. Until we were ready to implement it, there wasn’t much point to defining the “gameplay”, but as we’re coming up on the implementation, we can break the task into the following four tasks:
1) Attempt to always face the player
2) Stop when hit by a bullet
3) Reflect a bullet when hit from the front or sides, die when hit from behind
4) Charge the player if the scorpion gets a clear path to the player
And knock those out one-by-one. How far tasks should be broken down is going to come down to a judgment call, with the only rule being “not too little, not too big”. Too little, and you risk missing the spirit of the original objective, losing it to the details (this can be especially troublesome in a team situation where that “spirit” may not have been fully communicated). Too big, and you risk spinning your wheels and wasting time figuring out just what needs to be done (again, troublesome in a team situation if the person implementing the task doesn’t know what they’re supposed to implement).
How big or small tasks should be is one of the more touchy feely aspects of Agile development because so many factors can determine the best sizes, things like:
1) Experience of the person doing the implementing
(usually more experience means less detail is needed)
2) How well the game vision is being communicated/grasped by the team
(if it’s being grasped, it can be left vague)
3) How easy it is to check details with the lead or director defining the task
(if it’s not easy, it needs to be well defined)
4) How important the specifics are to the lead or director who wants the task done
(important means the specifics need defining)
5) How far along the project is
(earlier means more room for experimenting, later means less time to waste)
can all have an impact on how detailed individual tasks need to get.
Task sizes are a tricky subject, and everyone has an opinion on the best one, but it’s worth keeping an eye on them as inappropriate task sizes can drain a lot of time and resources.