Here's a feature teams routinely leave on the table: Stakeholder access. It's free, it's unlimited, and it gives the people around your Scrum Team a window into the work. If you care about transparency, and Scrum says you should, this is one of the easiest wins in all of Azure DevOps.
Stakeholders are users with free but limited access to the features in Azure DevOps. The Stakeholder access level can be assigned to an unlimited number of users without a license or subscription. That's worth repeating. You can give every manager, sponsor, and interested party in the building a real, live view into the product and process without paying a cent.
What stakeholders can do
The access level is deliberately partial, but it covers the things stakeholders actually need. With Stakeholder access, a user can add and modify work items, manage build and release pipelines, and view dashboards. They can check project status and provide direction, feedback, feature ideas, and business alignment to a team. They can also view information in the project wiki. In other words, they can see what's being built, watch it progress, and weigh in.
This maps neatly onto the Scrum notion of a stakeholder: someone who has an interest in the product and provides input, but who is not doing the daily work of building it. Used well, Stakeholder access takes strain off the Scrum Team. When you trust certain stakeholders enough to add them to the Contributors group, they can create and update their own Product Backlog items directly, rather than funneling every request through the team. For others, the read-only Readers group is the right fit.
Where the line is
Stakeholder access is intentionally limited, and that limit is meaningful. If a stakeholder needs to do something that supports the daily work of the Scrum Team, such as reordering items within a backlog, creating queries or charts, or touching code, tests, builds, or releases, then they need at least Basic access, if not Basic + Test Plans.
But notice what that really means. According to Scrum, if a person is doing that kind of work, they are no longer a stakeholder. They're a member of the Scrum Team. So the access boundary isn't an arbitrary licensing wall. It tracks a real distinction. Stakeholders observe and inform. Team members build. If someone crosses that line in practice, change their access level and acknowledge their actual role, rather than pretending a stakeholder is still on the outside.
The takeaway
Transparency is one of the three pillars that hold up empirical Scrum. You can't inspect and adapt what you can't see. Stakeholder access is a no-cost way to make the product and the team's progress visible to the people who care about it. Hand it out generously, set the right permission group, and let your stakeholders watch the value accrue. Sounds like good Scrum to me.