Currently we don't capture non-implementation stories and treat any research, analysis, release, and support work as team overhead. This makes it very difficult to predict team velocity.
What is the best way to capture these non-implementation activities so that we can more accurately report the load on the team?
There are typically two ways to use velocity with sprints:
There are advantages and disadvantages to both approaches.
When you only include value-driving stories in your velocity calculation then medium/long-term estimates can become easier to do.
For example:
The teams only includes value-driving stories in their velocity calculation and have a velocity of 30 story points per sprint. They are asked to add a new feature that they have estimated to be around 90 points of work. It seems likely this will take about 3 sprints to complete.
You can see how the Product Owner and stakeholders can find this approach easier to work with.
As you mentioned, the main advantage of including all work in the velocity calculation is that it makes it easier to get the right amount of work in each sprint.
You may want to try experimenting with both approaches and go for the one that works best.
This question is a close duplicate of What to do with work not on the board?. In my answer to that question, I articulate CodeGnome's Law of Transparency℠: "No invisible work, ever!" The Law of Transparency is just as applicable to your current situation because it argues against creating untracked work in the first place, precisely because that is part of what's generating the pain the Scrum Team is currently experiencing.
The short answer here is that "work is work," and treating certain types of work as second-class citizens makes them harder to track. The fix is for the Scrum Team to make all work visible through the defined Scrum Artifacts (primarily the Product and Sprint backlogs), and through other team-defined processes such as Kanban boards or other information radiators that provide information about available team capacity, iteration objectives, and the Definition of Done for each Sprint.
The 2020 Scrum Guide has a section on Scrum Theory that explains the need for transparency, and describes how various Scrum Artifacts can help provide it. Work is work. By deliberately excluding certain classes of work such as:
or any other activities that consume team capacity, you're creating hidden work that can't easily be tracked. That's the problem you're facing, and that's why you have drag on your velocity that can't be properly accounted for.
If you're doing this for tooling reasons, there's a related question about Why does Pivotal Tracker discourage estimating points for bugs and chores?. My answer there explains why feature-only velocity is an anti-pattern, and why story spikes, chores, support, and other work all belong on the appropriate backlogs.
You may also be doing this because your Sprint Backlog lacks the central coherence of a Sprint Goal to ensure that unrelated work doesn't suck up team capacity. If the team if missing its Sprint Goals because of work unrelated to the Product Backlog items selected by the Scrum Team and accepted by the Developers defined during Sprint Planning, that's often caused by untracked work or a lack of a well-defined Sprint Goal that can be estimated with reasonable confidence.
When my original answer was written, the 2017 edition of the Scrum Guide said:
The Scrum Master’s job is to work with the Scrum Team and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path.
At the time of this answer, the 2020 edition now says:
Scrum’s artifacts represent work or value. They are designed to maximize transparency of key information. Thus, everyone inspecting them has the same basis for adaptation.
Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured[.]
In either case, it's incumbent upon the Scrum Master to work with the Scrum Team and the organization to help the team find better ways to make all their work visible, estimable, and trackable. While the Scrum framework has plenty of built-in features to do this when properly leveraged, it really doesn't matter how you do it so long as all work is sufficiently visible to support the process the team wants to build, rather than leaving the root cause unaddressed within the framework's continuous process improvement cycles.
Why do you need to capture this type of work to predict velocity?
Velocity is the measure of getting valuable work done. You can measure velocity in points, stories, or whatever else. Whatever your unit of velocity is, your last iteration's velocity is the number of points associated with done work or the number of done stories.
Your overhead work will decrease the team's velocity. The more overhead work the people on the team need to do, the less time they will have to complete work from the backlog, which means they will get fewer units of work complete.
If you want to use velocity to predict future performance, all you need to know is whether the team's total capacity and amount of overhead work will be like the past Sprint or not. If it's similar, then you can use the past Sprint's velocity as a guide to help decide how much work to bring in. If it's different, you may need to adjust the amount of work.
Of course, I don't believe that velocity is the best way to measure the team's capacity or ability to do work. I believe that flow metrics, like throughput and cycle time are far better measures of past performance to use to plan future work. However, if your team is comfortable and having success using velocity, there may not be a good reason to change.
