The Scrum process in Azure DevOps is the closest fit to the Scrum Guide of any system process, but it isn't a perfect fit. Over the past decade the Scrum Guide evolved while the process largely stood still. The good news is that you don't have to live with the drift. You can customize the Scrum process to line it up with the Scrum Guide and with how your own team actually works.
You can't edit a system process directly. Instead, you create an inherited process based on one. Any changes you make to that inherited process automatically appear in every project that uses it, instantly. I select the Scrum process and create a child called Professional Scrum.
Process customization happens at the organization level, through an administrative web UI. The general sequence is straightforward: create the inherited process, customize its work item types and states, then apply it to new or existing projects and verify the results.
What I change
Once the inherited process exists and is set as the default, I make a handful of edits that pay for themselves.
- Disable the Bug work item type, so the team uses the PBI work item type for everything in the Product Backlog. Teams can add a "Bug" tag to those PBIs.
- Rename the Effort label to Size, which suits abstract estimation better than a label that invokes hours.
- Change the Business Value label to Value, because in Scrum value is value.
- Hide the Priority and Value Area fields from the form. I'd remove them outright if Azure Boards allowed it.
- Add Ready and Forecasted workflow states, then hide Approved and Committed.
- Hide the Priority and Activity fields from the Task work item type.
- Rename the lowest leaf-level backlog from "Backlog items" to "Stories," since in reality all backlog levels contain backlog items.
The result is a PBI form that says what a Scrum Team means.
One word of caution. Use the Scrum process the way it was designed for a few Sprints before you start bending it. I've watched teams rush to make a new project look exactly like their old one, dragging back fields like Original Estimate and Completed hours that were removed for good reason. Know what you're doing and why before you call it an improvement. Don't inadvertently change the rules of Scrum by customizing the tool.
Make the tool speak your language, then get back to building product.