What to do with work not on the board?

Question

TL;DR: At some point, someone on the team will have work which can justifiably not go on the board. How is this handled in a sprint team when it is a long running thing?

Our team's technical leader has a number of things to be working on to support the team, which only that person can do (because of responsibility, contractual obligations, skill/knowledge level or system access permissions). Should that work go on the board?

The above is a fairly simple Yes, in my mind.

The problem is that the work in question may want to be kept away from the rest of the team because it might cause a distraction (it may result in their current work being disposed of at a later date but for valid reasons), it might simply be more interesting (another distraction they may waste time debating), or that including it in the daily scrum and other ceremonies exposes it to certain product owners who do/should not need to know about it.

Compounding the problem is that higher management accepts that there is certain work which technical leaders take on which is "off board" but still valuable. Much of this is exploratory/PoC type work and (regardless of where the budget comes from) is required but not team story related.

Further, that work is also (by it's exploratory nature) nearly impossible to estimate as it is often very "blue sky".

How should this work be handled?

Should the technical leader simply report that they deliver a lower amount of time to the team's sprints than regular team members or should we absolutely commit to having everything on the board, regardless? Or somewhere in between?

Answer 1

You can have a technical leader. You can have him do work off the charts. You can hide this work from others that don't "need to know". You can reduce that person's capacity to make planning more accurate.

But you cannot call that Scrum.

One of the key features of agile (and, by extension, Scrum) is transparency.

Transparency: This means presenting the facts as is. All people involved—the customer, the CEO, individual contributors—are transparent in their day-to-day dealings with others. They all trust each other, and they have the courage to keep each other abreast of good news as well as bad news. Everyone strives and collectively collaborates for the common organizational objective, and no one has any hidden agenda.

Without transparency there is no inspection and without that there is no adaption. Those are the pillars of improvement. In other words, there cannot be improvement if you don't know the facts.

So yes, the work should be on the board. If it happens that only one person can do this job, then that is the way it is. Maybe it can be improved upon in the future.

But there can neither be a "technical leader" nor a person that has hidden agendas or side-projects in Scrum.

Answer 2

TL;DR

If the work matters, make it visible. If it doesn't, then treat it as muda and trim it as non-essential waste. You truly cannot have it both ways.

"No Invisible Work, Ever!"

CodeGnome's Law of Transparency℠ says "No invisible work, ever!" Any work that is off the books violates that law, as well as generally-accepted agile principles and practices. Invisible work leads to less effective communication, less accurate estimates, and loss of trust over time within the team and among stakeholders. So, don't do this!

100% of work that consumes team capacity should be reflected on your project plan. This means that work your team lead is doing should be on the team board, because:

1. It consumes a portion of team capacity, because the team lead is a member of the team.
2. Effort expended on these "invisible" tasks is effort that isn't being spent on something else.
3. It represents work-in-progress (WIP), which should have a visible impact on your WIP limits.
4. Estimates that ignore "invisible work" often fail to set stakeholder expectations, and may impact the accuracy of future estimates.

Invisible work is usually a project smell that indicates that legitimate work isn't being valued, or isn't being properly charged to the project budget. If the work is important enough to be done, or essential to delivering the product, then it should be visibly accounted for in the project's budget and plans.

This doesn't mean each minor task needs to be a separate user story or product backlog item. However, it does mean that it should be trackable work, and clearly reflected within the estimates the team is providing for its work. Pragmatically, this means that (at a bare minimum) the team lead's currently-invisible work should be:

• prioritized by the Product Owner as an essential component of product delivery,
• discussed during Sprint Planning to identify impacts on capacity and relation to the Sprint Goal,
• estimated along with all other work for the Sprint,
• documented on the Sprint Backlog for tracking, and
• deducted from available team capacity to perform other work.

If anyone argues that these things are unnecessary, or don't apply to the team lead's work, then you have a process problem. In that case, I'd take a long, hard look at how this work actually relates to the Sprint Goal and the team's process to determine if this work is truly on the critical path.

If it's on the critical path, you must make it visible to adhere to the Scrum framework. If it's not on the critical, then it's wasteful effort that should be eliminated. It's up to the Scrum Team to collectively evaluate this and come to the right determination for your project, team, and organization.

Answer 3

From the Scrum Guide:

Scrum is a framework for developing, delivering, and sustaining complex products.

Everything in Scrum is centered around the development, delivery, and maintenance of complex products. In this particular case, the keyword there is "product".

Everything in Scrum is also centered around three roles - Product Owner, Scrum Master, and Development Team.

Is the technical leader part of the Development Team? Based on the description here, it sounds like "no". It sounds like the bulk of the work done by the technical leader is not related to the items in the Sprint Backlog or in support of the Sprint Goal.

From the description, it sounds like the bulk of the exploratory work that you are describing falls into what I would call "discovery" or "concepting". The bulk of this type of work tends to be more product or user centric and less technology centric, but that doesn't mean that there isn't a need for a technical person to support this work in various ways.

There are other types of work that also fall into a category that isn't "delivery". If the technical leader is participating in things like Three Amigos sessions to get Product Backlog Items ready for the team to refine, that doesn't need to be on any of the backlogs. If the technical leader is holding 1:1s with team members in a management capacity, that doesn't need to be on the backlog, too. If the technical leader is doing work like enhancing the development and test tools, that also doesn't need to be on the backlog (although if it was a Sprint Retrospective item, it may be related to a Sprint Goal).

Unfortunately, Scrum is silent on how to do this.

I'm going to present this slightly differently.

Is the work of the Product Owner or Scrum Master made visible on the board? If not, how do you make their work visible to the entire Scrum Team or to stakeholders outside of the Scrum Team? If this exploratory work is more closely aligned with creating the Product Backlog and preparing Product Backlog Items for the team, could the same strategies used to make the Product Owner's work more visible also apply to the work of the technical leader?

Answer 4

I assume this isn't a 1-time thing, therefore my suggestion is to reduce the resource's allocation on the project that owns the board.

Big Extreme Example -- let's say Bob puts 50% of his efforts into Project A for Company 1 and 50% into Project B for Company 2. You wouldn't expect to see his work from Project-A to be on Project B's board. "Why does Bob only have 20-hrs of work on the board any everybody else has 40?" -- well, Bob is only allocated 50%.

Small Extreme Example -- Every month we have one team member that is allotted a few hours work to learn something new; they present this to the team. This is work that must occur, but does not appear on the board and doesn't get reported during standup. During that month, the team member is less allocated to our main project (let's say 90% allocated).

If your case, if you feel the work belongs a board, I'd suggest a second board. Unlike the first example, you're the same company and have related resources. You can indicate the "10% allocation to the other project" by putting a "10% Allocation" task on main the board. It isn't anything that would distract the other team members, but it is a reminder that effort is going elsewhere. Your second board can have details.