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.
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:
- It will ensure that work abandoned before it is complete will be visible to the team.
- 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.
- The average throughput for queued jobs can be be measured, providing feedback about team capacity.
- 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.