What is good criteria for deciding what constitutes an individual task?

Question

My own background is in software dev and I've started work as a network engineering PM recently. In my previous PM work, creating documentation was a separate task. It was sometimes done by the software engineer who completed the task that needed to be documented, but sometimes done by someone else like a technical writer or junior engineer (then checked by the senior engineer). So it was a separate task with the task list looking something like this:

• set up XYZ
• document XYZ configuration

In this environment, before I was around, they established that they don't have documentation tasks, that uploading documentation was what you did before you checked the task off because they say that it is not really complete unless it's documented. The result is I have a ton of tasks along the lines of "Set up XYZ" that are just hanging open because the person responsible doesn't have time to do the documentation yet. Their argument is that we have too many tasks already, that we have "task bloat." Indeed, we have some task lists that are 30 tasks long and it does seem a little daunting at times.

But I don't like this current practice because it looks like things aren't done in our PM software (TeamworkPM), which our clients also participate in and also I think sometimes the documentation tasks can be delegated to other people.

What is good criteria for deciding what constitutes a task? How can I balance granularity and "task bloat"?

Answer 1

TL;DR

Your problem is not actually with granularity or "task bloat." Your core issues appear related to exceeding the team's work-in-progress capacity, and allowing the team to ignore the agreed-upon definition of done.

Integrating Documentation with Tasks

Network engineering is not like programming. While collecting router configurations could conceivably be done by someone else after the fact, documenting which port in a 24-port switch was just attached to some jack in a punch-down block is something that would take an unreasonable amount of time to figure out after the fact.

In the main, your team is probably right to make documentation part of the definition of done for each set of tasks. Unless you have some upstream requirement to track documentation separately from other work, it seems likely that your problems lie elsewhere.

Analyzing Process Failure

In my experience, if documentation is part of the definition of done but someone says:

I have a ton of tasks along the lines of "Set up XYZ" that are just hanging open because the person responsible doesn't have time to do the documentation yet.

the problems can usually be traced to inaccurate team-capacity estimates or a team-wide failure to comply with reasonable WIP limits. Some common root causes may include:

• Management pressure to do "real work" instead of documentation.
• Teams that are multi-tasking, rather than working effectively on one task at a time.
• Individuals moving on to the next task before the previous task is fully complete according to the agreed-upon "definition of done."

You will need to work with your team, who you've said already agree that the "definition of done" includes documentation, to identify why documentation isn't being completed. Whatever the reason, the likely solution is to implement sensible WIP limits.

WIP Limits

Work-in-progress limits represent the number of active user stories or tasks that your team actually has the capacity to complete in a sustainable way. In your team's case, jobs waiting to be done should be queued until there is sufficient capacity to pull the job through all required stages for completion. This includes performing the work and documenting the cabling or configuration changes properly.

Determining your team's actual capacity will require some work on your part, and the active cooperation of your team. Although your mileage will vary, as a rule of thumb I recommend that work in progress never exceed:

• the number of folks available to perform each task,
• the number of swim lanes on your kanban, or
• the number of columns on your kanban.

You may find that your team can handle more or less in-progress items than indicated by my rules of thumb. That's fine; the important thing is that you identify your team's sustainable capacity.

Benefits of WIP Limits

Even if you're not using the Kanban methodology, WIP limits will accomplish a number of things for you and your team:

1. It will ensure that work abandoned before it is complete will be visible to the team.
2. The size of the queue will provide your organization with valuable feedback about whether resources are adequate to process the volume of incoming requests within the desired cycle time.
3. The average throughput for queued jobs can be be measured, providing feedback about team capacity.
4. The average cycle time of jobs from acceptance to completion can be measured, and processes (or resources) adjusted if the cycle time is not adequate.

Once you are able to track work more accurately and identify process problems more clearly, solutions may present themselves. Even if the answers don't jump out at you, this will at least give you a reasonable place to start.

Answer 2

Great question, and I believe in keeping this as simple as possible without adding too many "rules" to what constitutes a task.

A PO creates a requirement that needs to be done, this requirement requires work to be done in order to the job done. This work comes in the form of grooming analysis, coding, testing, documenting, deployment packaging, UI design and many others depending on the type of product.

Each one of these constitutes a task. Thus you will create many tasks for grooming, UI design task, coding, testing. Each task then be executed and done when a team member has capacity to do it. For example test data preparation can easily start before coding or TDD/BDD tests can be created with stubs.

Check-in Rule

I like to create tasks at these boundaries

1. Something a developer can commit to the source repository. For example, a developer can create the database schema and commit that; an ideal task.
2. When a handover between different skills is needed.
3. When a bit of work exceeds more than 1/2 a day. One needs visibility of what is being done and tasks that take days adds risk to the team.
4. Tasks should contribute to the Definition of Done.

Balance of task size

Try not create too many tasks that a developer is updating task statuses every couple of minutes. This adds unnecessary overhead and frustrates the team. However, don't make them too big that a developer works on it for days without indicating progress. The team and other stakeholders need to see progress being made.

Grooming Tasks

Often when having a Business Analyst in the team that does product backlog grooming, I normally put a task on an Epic that needs grooming work. The task, simply requests grooming of the PBI and is then estimated in hours. The goal is for the BA/PO and possibly team to groom the PBI and get it to a Ready state for the next sprint. Doing this helps the team remember to to grooming and it also "accounts" for the activity.

Done

Having a simple wall To Do, In Progress *and Done* makes it easy to see the health of a requirement. Thus if there are still tasks to do, the team need to pick up the task to get it done. Once all tasks are Done, then the requirement is ready to be reviewed by the PO.

Dealing with Change

I encourage teams to add tasks and remove tasks in the sprint as to help communicate what needs to be done. I don't believe in hardening the tasks as the reality is, if there is something the team forgot this will not change; thus rather make it visible and add the task.

Coaching Guidance

Keep it simple and don't add too much process to it.
Let the team self organise on how they want to deal with tasks and its not a PO/Stakeholder/SM responsibility. But, these people have the right to ask the team for daily progress updates; i.e. what is remaining to be done for the sprint.

Answer 3

The answer is going to be heavily dependent upon what your organization and sponsor want in terms of control and oversight over a project. For example, if your organization's culture is very much about tracking at a very fine level you may not want to just track delivery of the documentation, but also when it is first drafted, when it is reviewed, when it is revised, when it is accepted and when it is published.

Your main responsibility here is to articulate what is required in terms of resources and time to generate the desired level of oversight, and facilitate tailoring of what is wanted to what is going to add the most value given the criticality and complexity of your project. On a current project of mine I started out with a high-level plan of maybe 80 tasks that morphed into one of ~250 by the time all was said and done, but the team was engaged and bought into the belief that such a level of detail was necessary and added value for the project.

With all that said, is the root cause of the problem really with your task lists? It seems to me that it is more likely your team members are over-tasked, it might be more productive for you to see if they can delegate the documentation effort to someone else on future projects.

Answer 4

You break your work down to the level of abstraction YOU need in order for YOU to manage it, balanced by the cost associated with YOUR chosen level of granularity.

The only question that has to be answered is, do you know where you are, do you know the health of your project, do you know where you are going? If you cannot answer those questions, then your breakdown is broken.

Avoid criteria. There are an infinite number of scenarios that there can be no set of criteria that will work in all of those situations. The PM on record should have the authority to break down the work to suit his/her management needs.

Answer 5

Since it is clarified now it is end user documentation like user manuals etc.. Here are my thoughts:

• User manuals are very important for the end user. Need to educate your team how important it is for the end user. With out this Users may not be comfortable of new features developed.
• Include this task in your plan and you could get this done with junior developers or college interns if you have any. Final document review should be done with SME(Subject Matter Expertise) and with Senior members of the team. Send the end user after implementing the review comments. High quality documentation helps end user very much.
• The other way of educating the team is give your team members a new software with out documentation and ask them to perform the needed task. Ask them to note down the challenges they face too.
• Brainstorm the challenges on this and get team buy-in to implement the agreed improvements.