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"?

5 Answers 5



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.

  • I agree. The fact that they are having trouble completing this kind of things should definitely be taken as a sign they are over-tasked and I need to work with them on this. These two late summer months are always the worst because so many people go on vacation.
    – Melissa
    Commented Jul 12, 2013 at 16:34
  • 1
    I'm working on a project where we're really focusing on controlling scope, and paying attention to WIP limits is key to ensuring we can meet our definition of done. We tend to overlook documentation in our estimates, and as a dev I'll start doing that! I'd suggest adding to this already-great answer that including the documentation estimates in the total task estimate will help ensure there's time to complete the task. Documentation is sort of like technical debt, you just have to work it into the estimate.
    – jmort253
    Commented Jul 13, 2013 at 17:52
  • 1
    @jmort253 I agree with everything you said above, except that if it's already agreed to as part of the definition of done then (by necessity) it should already be factored into the estimate. Upvoting your comment, but my initial reaction is that this isn't really an estimation question, and addressing estimation in the answer might distract from the answer's central focus on WIP limits. I will certainly think about it, though, and your points are certainly well taken!
    – Todd A. Jacobs
    Commented Jul 13, 2013 at 17:59

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.


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.


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.


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.


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.
  • Hi Sreedhar, from Melissa's question, I get the impression the documentation is for IT or end users, such as configuration documentation, not design/requirement docs. Also, it sounds like Melissa is the person who either doesn't consider the documentation important or doesn't consider it her job. Melissa, please feel free to clarify if that's not the case. :)
    – jmort253
    Commented Jul 12, 2013 at 2:34
  • I consider the documentation important and in fact I do sometimes do it myself, particularly if it is for end users, and I feel that more granularity would allow it to be assigned to me
    – Melissa
    Commented Jul 12, 2013 at 16:10
  • Ok it is not very clear which documentation team is not preparing. My assumption is even the design/requirement docs. Commented Jul 12, 2013 at 16:21
  • no, those are all done at the beginning, I'm mainly talking about for example a document telling users how to log in, a document for the rest of the tech team telling us the server structure in case we need to work on it ourselves, etc.
    – Melissa
    Commented Jul 12, 2013 at 16:31
  • 1
    I think a major thing I'm going to do now is work out to see which documentation can be delegated to others (stuff for users for example) and which really is just part of completing the task
    – Melissa
    Commented Jul 12, 2013 at 16:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.