As we coach software development teams in Kansas City, we are often asked about the process of breaking User Stories down into development tasks (anything related to implementing and verify a User Story). This is one of the areas teams struggle with when adopting an Agile process. It’s actually something they often struggle with using most any process but most Agile approaches rely heavily on it for a number of reasons.
1. Iteration Planning
Tasks are a good last check for iteration planning purposes. Even though we can rely (to some extent) on past actual velocity to get a sense of what a team might be able to achieve in subsequent iterations, breaking stories down into development tasks/hours allows the team to leverage what they’ve learned so far during a given release in terms of some stories being potentially larger or smaller than previously thought. They can use that information to develop a better, more reliable/realistic iteration plan.
During planning, openly discussing development tasks gives all team members a view of what will take place while implementing the stories selected for the iteration. During that discussion they can help each other clarify and improve their development plan and discuss lesser known areas of the code, database, etc. to help other team members learn and become more productive in their development.
2. Iteration Burndown (what’s left <how many hours> to do within a given iteration)
Having tasks with hours estimates enables the team to discuss (during the Daily Stand Up meeting) why certain tasks might be taking longer than planned, why some tasks were overlooked when a story was initially discussed, why some tasks weren’t ultimately needed. With this information, it becomes apparent that at times, developers may be struggling with a given task and may need help.
It also enforces thinking more thoroughly about tasks needed to complete a story and aides in becoming better at tasking and task estimating during subsequent iteration planning meetings. It also allows the team to get an earlier sense of whether the goals and story points planned for a given iteration will be achieved and allows the team to consider adjustments sooner.
Defining and estimating tasks makes team commitments to an iteration public knowledge and increases
the sense of urgency of getting better at task definition and estimation. It also can help with maintaining a sense of focus on agreed upon tasks and indirectly trims waste related to gold plating. It can encourage team members to seek assistance on tasks they might be struggling with as their 2-hour task still isn’t done after a couple of days effort while the teams velocity begins to become negatively impacted.
Developing for a story without tasks can lead to stories that don’t get done or done as hoped. Without tasks, the team loses the ability to provide assistance (since nobody knows what you’re doing) and overall iteration and ultimately release predictability suffers.
4. Shared and Individual Learning
Discussing, defining, estimating and tracking tasks allows the entire team to learn about the problem domain, especially when the domain or parts of it might be new to certain team members. It also helps all team members become better about planning the work needed for all stories and helps them to become better definers and estimators of tasks.
5. Tasking Encourages Better Design
Thinking through a plan of attack for implementing user stories and creating steps (a.k.a tasks) to achieve it tends to create a higher level of focus and optimize overall productivity. It also facilitates design discussion often resulting in better and more complete story implemenation.
6. Forecasting Velocity
When you don’t have the luxury of running an iteration to get an actual velocity but need to provide stakeholders with some sense of cost and schedule, you need to forecast the teams velocity. Using tasks is very effective for this. Do this by estimating team capacity, breaking stories down into tasks/hours until the capacity is filled and adding up the points for the stories you just tasked. You now have a forecasted velocity to provide a preliminary forecast of cost and schedule.
7. Tasks Serve as Reminders
When you task, typically at the beginning of an iteration (during the planning meeting), you have the users attention and are able to ask questions to which you’ll need answers to enable you to think about your plan of attack for a given story in terms of development tasks that will be necessary. Even a few days into the actual iteration, you’ll forget at least part of what you discussed with the user if you don’t have recorded tasks and you’ll have potentially less access to the user to confirm/reconfirm tasks and/or stories.
8. Talk to the Dog
Having to talk out loud and/or in a public setting about tasks you’d need to complete a user story tends to create greater focus than just beginning to code. It typically creates better overall productivity and thoughtfulness in approaching the implementation of a story.
9. What if you hear, “I can’t/won’t task.”?
If a team or team member simply says they won’t task, that’s more of a personal discussion. Obviously asking them why they won’t task would be a useful starting point, it may ultimately speak more to ego, personality or an underlying resistance to change.
When a team or team member claims they can’t task you have more information to work with. A common stated reason is that they “just have to start coding” and don’t really know about the tasks until they start working on it. One approach is to say “Fine, then write down the tasks as you uncover them during coding and we’ll discuss and learn from those to make you a better up-front tasker.”. You can also allow a “research” task (2-4 hours) to allow a developer to spend time looking at the code, database, etc. for purposes of ultimately tasking a user story.
Above are just a few broad reasons why tasking is useful for software development, in particular for Agile processes.