Taarradhin

There are five levels to Agile planning:

1. Product Vision – What are you building, why, when and for who.
2. Product Roadmap – Everything related to the releases needed to meet the vision; themes, features, objectives and dates.
3. Release Planning – Everything related to meeting the goals of the release, the iterations, team and capacity, stories, priorities and estimates.
4. Iteration Planning – Everything related to meeting the goals of that iteration’s stories; tasks, definition of done, effort, commitment.
5. Daily Execution – What did I do yesterday? What am I going to do today? What impediments do I have?

This month I want to talk about a piece of this planning that I feel is often overlooked and loathed by many but very important to the level of success of the team – tasking.

Usually when I’m training and this topic comes up, I’m immediately met with resistance –

“I won’t know what I need to do until I get into the code.”

“Too many things can impact how I do it.”

“It’s impossible to know how I’ll go about it until I get started.”

It feels like micromanaging to some and overkill to more but when you’re struggling to meet dates, find yourself often stymied by something unplanned or struggling to get a customer to get you something you need to move forward, tasking will help.

In the iteration planning meeting, after the stories are reviewed, estimated are verified and the acceptance criteria is finalized, the story is broken down into individual tasks. These tasks can be done at whatever level the team is comfortable at. My team does a task per day, per story and often groups smaller tasks into buckets that are understood by everyone. A single task for creating a web form vs many task for each individual part.

These tasks are then laid out on a calendar against time off and holidays, dependencies are double checked, and the schedule is reviewed with the customer. Once all of that is done we determine if the schedule will work for the team. If it does, we commit to following it. If it doesn’t, we take another look.

Once we’re able to commit, the tasks get entered into our iteration burndown chart and discussed in our daily stand up.

I like to call tasks the warning bells of the iteration, if they’re taking longer than expected or getting blocked then it’s a signal that you have a story at risk of not being completed. Its clear right away and you’re able to work to fix it before it goes too far. They also help point out flaws in your process; Are you consistently being blocked by the same issues? Are your stories being scored accurately? Are you asking the right questions during the planning meetings? Are you too optimistic in your planning?

Tasking helps fulfill two of Agile most important philosophies (in my opinion); Kanban and Kaizen. Kanban is a visual signal, a warning, in this case, that is easy to see, discuss and resolve or plan for the next time. Kaizen is continuous improvement, the process of regularly reviewing your effort and making improvements to be better in the future. During the retrospective, it’s easy to look at a story that had issues, understand where specifically the issues happened and then plan for how to mitigate or resolve those issues in the future.

Other things that tasking can help with – building an understanding within the team of what steps are needed to accomplish a task, assessing the accuracy of your estimates, increasing transparency to the entire product team on the scale of effort for each story and ensuring that dependencies are met on time.

Without tasks, you wouldn’t catch a potential issue until the story isn’t completed in time. Sure, that helps when assessing the health of the release but in my mind, that’s too late, you should be intervening before you fail to deliver.

Tip – When you’re coaching someone who says “But I won’t know the tasks until I get in there” try these two approaches: pair them with a developer who can help them pull the tasks together or have them capture their tasks every day for an iteration to help them get the concept down. I find that the majority of the time it’s fear that drives that statement, giving them some back up and a sense of security will go along way.