Within the Agile community, the use of User Stories is a very popular method of building, categorizing and prioritizing components of work. The approach follows a very simple and easy to understand structure that teams use in order to build value for their respective customers. User Stories, when written correctly, can be understood by stakeholders, customers, line of business managers and the teams that will build value. This structure, which has worked well for many organizations is a way to help bring consistency and alignment across the enterprise; up to and including actual customers. In addition to User Stories, many teams decompose their actual work lists into items called Tasks. For new and even some experienced Agile teams, tasking stories can be confusing and, at times, burdensome. The purpose of this article is to address some of the common concerns around tasks from two viewpoints (theoretical and practical application). The intent is to provide you, the practitioner, with information that can help you in your Agile journey at the individual, team and even organization level.
Task Planning Top Five
Davisbase strives to develop teams that deliver value. Organizationally, task planning is a value based activity that provides teams with a tremendous amount of visibility. This visibility provides the team and organization with a high degree of transparency in regards to the actual activities that are needed in order to create valuable applications. As you move forward in your respective task planning activities, we’d like to share our top five reminders:
- Task Planning is done by the team
- Task Planning activities are for the team
- Create a task planning approach as part of the team’s working agreement
- Wherever possible, tasks should be broken down into units of work that can be accomplished in a day
- Tasks should be specific enough to be understood by multiple team members
Who are tasks for?
When teams begin to discuss and determine the best way to complete User Stories, they are already creating a sequence of events (initially verbally) that they will follow in order to accomplish the intent and desire of the User Story. For many team members, the process of writing their approach down via “tasks” is a very logical process to follow. Creating tasks and assigning them to a User Story will give the entire team the visual representation that they deserve in order to complete the work. As such, organizations should always encourage that tasks be written by the team, given the fact that tasks are for the team. It is natural and common that individuals outside of the team may understand the tasks (i.e. ScrumMaster, Product Owner, DBA, Architect, etc.), yet it’s always important to know who the tasks are for. Tasks are for the team.
Anti-pattern: As coaches, we’ve seen examples where tasks are written by the “leads” for the team. This should be considered an anti-pattern in that teams deserve the chance to self-organize and create their own work approach. “Leads” are important to teams, yet these members should write their own tasks and encourage others to do the same. Of course, there will always be exceptions to this statement, but make sure that the team has the opportunity to have the discussion.
What are the right kinds of tasks?
Teams have the freedom and responsibility to determine the best way to complete their work. As such, the right kinds of tasks will be depicted by the team on a story by story basis. Ideally, tasks should be specific enough to allow the team to recognize that a specific increment of the story has been completed. In some aspects, tasks may be tied back to the acceptance criteria that was written for the story itself. In addition, many teams will create a task structure as part of their team working agreement. An example of a task structure could include items like:
1. Development tasks
2. Peer Review tasks
3. Code Review tasks
4. Development unit test tasks
5. Quality tasks
6. Quality test tasks (manual, automated, etc.)
7. Review and acceptance tasks
Anti-pattern: For those of us coming from a project management viewpoint, we’re always looking for structure and consistency. It’s natural for us to want to create process, but we should always remember that the team’s own the tasks, just like they own the commitment. Encourage teams to create their own working agreements and task structures, but realize that each team is different and not all User Stories will have the exact same task structure.
What is too generic?
Tasks, as defined and written by the team, should be specific to the individuals working on the task and/or the team at large. Writing tasks is repetitive on a story by story basis and is an activity that will continually take place for the teams. While many teams create tasks and assign those tasks to team members, some teams write tasks that are specific enough to be picked up and work on by one or multiple people. Making tasks specific should be considered a best practice because the specificity will provide the team with necessary information in order to execute the work. Avoid writing generic tasks like this real life example below wherever possible:
1. Code story
2. QA task
3. DEV only task
4. QA only task
Anti-pattern: Agile teams strive to have all work visible, including tasks. While the tasks are certainly for the team, generic tasks can provide a false sense of security to both the team and anyone else who looks at the tasks. The false sense that can be derived is that not enough discussion has taken place by the team in order to determine the best approach for completing the story. Writing specific tasks can and will alleviate this concern.
What is a well-written task?
Well written tasks can be understood by multiple people on the team. As coaches, we believe that tasks have value and that the value is recognized incrementally as the User Story moves through various states (eg. defined, ready, in process, completed, released, etc.). An excellent best practice is encouraging task review (where applicable) as part of the Sprint/Iteration Planning process. Many teams may begin their work by writing standard tasks together and then splitting off into different areas to write additional tasks. Yet, those same teams will always come back together in order to review the tasks that have been written.
Anti-pattern: Don’t rely on team leads or SME’s to write tasks for the upcoming Sprint/Iteration. Active participation should be anticipated and encouraged by anyone who will be doing actual work on the User Stories.
Should they be estimated in hours? If yes, how many?
For teams that are new to an Agile mindset, many coaches will recommend that tasks be estimated in hours. The primary reason for this approach is to allow the team the ability to compare their tasked hours against their available hours for the upcoming Sprint/Iteration. This is an important activity that will help the team make a determination if they can commit to the body of work that has been provided by the Product Owner.
In addition, many coaches believe that tasks should be broken down into units of work that can be completed in less than a day. This is an excellent approach for new teams, yet we’d like to offer another viewpoint by saying, “Encourage teams to break down tasks into the smallest unit possible that provides value”. In our experiences, we’ve found that tasks are still items that can be completed in less than a day; yet understanding and thinking about value helps many people take their understanding and appreciation for the work completed to higher and higher levels.
Finally, some organizations have gotten to the point where they no longer estimate tasks in hours. These are usually found with very mature teams that have worked together within a very specific organizational culture. For those, the concentration is truly centered around value creation and value recognition throughout both the organizational hierarchy and via the customer community.
Anti-pattern: Avoid forcing teams to write tasks that must be completed in a work day. This will stifle the team on many different front. Encourage task creation that provides a solid understand of how the problem will be addressed. Encourage team members to determine the “best way” to solve the User Story. And finally, encourage team members to write tasks into specific items that have incremental value towards the successful completion of the User Story.
Are they just for one person?
As mentioned above tasks are not always just for one person. Teams that use both pairing and peering approaches will structure their work in such as way that more than one person will work on a task at a specific point in time. In addition, some teams don’t assign each and every task to a person prior to making a commitment and then executing against the commitment. Therefore, some tasks may not have one owner…they may have multiple owners. It is important to note that many of the tools in the open market don’t allow tasks to be assigned to multiple people at the same time. Some organizations have circumvented this issue by creating general users within their systems that represent two or more people.
In addition, it’s very important to understand the team member skill composition mix (generalists, specialists, generalized specialists). An awareness of this structure will be very beneficial in understanding which tasks should be assigned to a specific person versus those that may be assigned to multiple people. For some, this may seem like an intermediate to advanced concept. If you’re new to “tasking,” see how many of those tasks can be assigned to just one person. That will definitely get the conversation started in the right direction. You will find that many of our experiences will assign tasks to just one person. At the same time, the exceptions to the rule help to better understand the dynamics of the team and will help skills develop and organizations mature.
Keep push your own Agile limits and remember, “championship teams are not created when it’s perfect outside”.