Sprint Tasking Tip: Strongly prefer more granular tasks


This tip is just one of the roughly 30 tips that comes from my Sprint Tasking Tips article.

Two schools of thought: More updating or more granular

There are generally two main schools of thought about how to task out a sprint in hours. One thought is to create tasks that are a bit larger in size, but to re-estimate each task that is in progress at some point of every day, usually whenever the burndown is updated. The Scrum Guide is pretty specific on this — the task estimates must be updated daily so that the burndown reflects a very good estimate(to the team’s best knowledge) of the amount of work remaining in a sprint. In addition, according to the Scrum Guide, 1 day is the largest a task can be anyway.

Another school of thought is to make lots of tasks, and make them small, such that the need for the daily ritual to update each “in progress” task’s remaining time is really not necessary. Using this method, the burndown will still reflect very accurately the amount of work remaining in the sprint. For this strategy to work, though, the tasks need to be preferrably closer to a half day or less in size. I strongly prefer this method, because having to update each “in progress” task every day, especially when the tasks are larger, is a logistics nightmare and not terribly enjoyable(not to mention reminiscent of WaterRUP). Besides, smaller tasks reduce bottelnecks, increase transparency, and generally allow teams to optimize effiiciency better, as we’ll see below.

Granular is good!

*Development Managers, Project Managers and Team Leads: Don’t be afraid to be very detailed at the Sprint tasking level. Read this section verbatim!*
For the sake of transparency and many reasons that will become apparent below, granular tasks are good. By granular, we mean prefering tasks that are 1-4 hours of ideal time per person involved in the hopefully small, atomic, and discreet task. Many experienced Project Managers and Team Leads seem to fear this type of granularity. I think this fear is a holdover from traditional project management and WaterRUP techniques, and the use of planning tools like Microsoft Project. In traditional project management, making tasks too granular has disastrous consequences, and requires a huge amount of tedious maintenance to keep the project plan leveled and up to date. It doesn’t help that traditional projects would last for months or years, thus making granularity exponentially disastrous.

*But wait! Stop the presses! Take off those pukey colored “WaterRUP” glasses and let’s enjoy the Agile view for a minute.*

  • Agile processes like Scrum thrive on short cycles. The Sprint Backlog is the project plan for a single Sprint. Sprints in Scrum are limited to 4 weeks in length, and most teams choose a Sprint length of 2 weeks. Because of this, the Sprint Backlog’s project plan duration is literally *never* more than 4 weeks in length, and usually not more than 2 weeks in length.
  • The Sprint Backlog is never created in advance. That’s right, I said NEVER! You will almost never have to do any significantly sized re-working of the project plan because it is created just in time and your crystal ball only has to look 1-4 weeks into the future. So, the entire lifetime of this Sprint Backlog is never more than 4 weeks.
  • The Sprint Backlog is discarded after the Sprint. Yes, that’s right, I said discarded. You are never again chained to a project plan that never ends. You can literally tear up this project plan after 1-4 weeks!
  • More granular tasks leads to higher transparency, making it easy for you to know exactly what is going on within the team.
  • More granular tasks leads to a more accurate prediction of work remaining (aka The Sprint Burndown)
  • More granular tasks leads to a better comparison with the capacity burndown(aka “the ideal burndown line’). As such, timeline risks are almost immediately identified in real time!
  • Tasks are created and maintained by the self organizing development team, so no secretarial duties specifically for Project Manager types, like having to futz with MS Project or some other project data entry tool.

For the rest of the tips, I will assume that you’re going the more granular task route, but many of the concepts will translate to using larger tasks as well.

Link to full article:  Sprint Tasking Tips

What are your favorite Sprint Tasking Tips?  Post them in the comments.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: