TL;DR
Within Scrum, or any sane project management process, there should never be "invisible work." All work that impacts the project's budget, scope, or schedule should be visible to both the team and the organization.
In essence, you are getting hung up on the idea that backlog items or user stories should add value to the product (in your case, a software product), and that anything that isn't part of the software product is therefore an externality. This isn't so; externalities, infrastructure, technical dependencies, and internal process all impact project deliverables and resources, and should therefore be classified as either trackable deliverables or trackable impediments.
Your only viable solution is to make the work visible, and then either charge the cost of that work to the project or accept it as an external dependency. In other words: document it, track it, and adjust for it.
How to Classify "Setting Up a New PC"
For example, you are part of an agile team and have a sprint in which you are expected to build and deploy code, but at the same time you need to setup a new employees pc that is starting next week?
Setting up a new PC is something that is either:
- Outside the team's scope (e.g. it's handled by the facilities department, or some other external resource) in which case it is an obstacle to progress that must be accounted for rather than a deliverable.
- It is a deliverable for the team. Your cross-functional team does have someone capable of installing a new developer's workstation, right?
From a framework perspective, it doesn't really matter how you classify it. The classification will simply help the team identify those things that need to be done by the team as work chargeable to the project, or help the organization capture external dependencies that will create drag on the project and that will impact the number of stories the team should accept into the current sprint.
Important Note: If you're expecting a brand-new developer on a team to do anything other than create some initial drag on that team's velocity, with or without the benefit of a new workstation, then you are probably Doing Scrum Wrong™. Velocity measures capacity, not management targets, and capacity generally drops when adding new team members due to the necessary overhead of bringing them up to speed.
External-Dependency Stories
In the first case, the user story is reliant on an externality, but should still be a visible cost to the team. For example:
As a new developer,
I need to requisition a new workstation from IT
so that I can be productive.
There may be tasks for the team, such as filling out requisition forms, or going down to the IT department and checking on the status of the new workstation. However, whether or not there are tasks for the team is largely irrelevant; the story is low-effort for the team, but is largely outside the team's ability to influence directly in terms of speed of delivery.
However, it is often useful to have these sorts of stories included on the backlog because they are:
- A cost to the project, both financially and in terms of time.
- A project dependency that must be tracked.
- A coordination item that should be addressed in the daily stand-up until it is resolved.
- A process step that should be inspected during the Sprint Retrospective, and adapted if the process isn't meeting the team's needs.
Internal Stories
In the second case, the new workstation is actually a deliverable for the team. If such is the case, then the team should estimate the level of effort involved in ordering, configuring, and installing the workstation the same way that all other project deliverables and dependencies are estimated.
This also provides levers to the Product Owner to manage the project's budget. If the story is something the Product Owner wants to prioritize, then this may indicate that there's value in having a new PC overnighted rather than shipped by Snail Express™. The Product Owner, through the Product Backlog, can determine each and every sprint whether project budget and resources should go to:
- feature delivery, or
- essential project dependencies.
Product Owners Responsible for Prioritizing Non-Feature Stories, Too
Bringing on a new team member, and all the associated processes that entails, is something that impacts a project's resources. It is therefore up to the Product Owner to manage the allocation of those resources.
If the Product Owner chooses to de-prioritize stories related to purchasing essential equipment or providing training to a new hire, that's a trade-off that can certainly be made as long as it's explicit. Likewise, if the Product Owner decides to emphasize new equipment and training this sprint in order to improve team capacity in future sprints, that's also a legitimate choice to make explicitly through the Product Backlog.
In either case, the Scrum framework provides for these decisions to be made visible and explicit through placing all project-impacting stories on the Product Backlog. That means that procurement and training stories belong on the Product Backlog, too; it's not just a place where software features sit around waiting to be implemented.
If you're following the official Scrum framework, then I strongly recommend that you add these tasks to the Product Backlog and allow the Product Owner to take responsibility for prioritizing them. If you're following one of the many pseudo-Scrum variants, then you may simply need to reduce your team's expected capacity and accept fewer stories into each sprint until the team has finished properly integrating the new team member.
I can't think of a single case in my own experience where bringing on a new hire doesn't represent a cost to the project or to the organization. Why not make that cost visible, rather than sweeping it under the rug?
