The default Azure DevOps Scrum process is good, but I think it adds some unnecessary complication. Below I'll walk through inheriting from and modifying that process. I'm building on the work in my post A Simple Intro to Scrum in Azure DevOps, so you should start there if you need to.
Lots of what's below is my opinion, so take it for what it's worth. But don't discount it, that's mean.
In my experience, when Developers, Scrum Masters, and Product Owners get their hands on electronic project management software, they add and add to what's already there. This is usually a mistake. Instead, pare down to the simplest thing that works, and only add features when needed.
As an aside, the other thing organizations do is try to enforce a single process on all teams. This is not Agile, because it removes team autonomy, self-organization, and effectiveness. The usual reason given is to make reporting across teams easier. That gives too much weight to upper management control. Instead, ask Developers to help figure out how to deliver cross-team reports. While you're at it, see if you can pare down those reports, too. Ask, "How is this report delivering user value?"
One way to find the simplest thing that works is imagine--or put--it on paper. Here's all we're really trying to capture.
The work item structure is:
Stories and bugs move through a board.
A story or bug card--sticky note version!--might look like this and has all the relevent info plus pointers to more detail.
Try to keep your electronic version that simple.
A New Process
Open Azure DevOps and open the Organization Settings > Boards > Process
Select Scrum > Create inherited process, and name it SimpleScrum
Open the SimpleScrum process. Under Work item types, we already have an essential set of types. Let's start by creating a work item type named Story instead of Product Backlog Item (PBI).
No, you can't rename an inherited process work item type. I hate this, and so do you.
Open the PBI work item type > States, and hide the Committed state.
In the original tab, choose New work item type and name it Story
Under Layout, add and update the fields to look like this. In one case, you're renaming Description to Value (orange), in others you're using an existing field (green), and in still others it's a new field (red).
Under States, add two new states: Active in the In Progress category and Removed in the Removed category, and remove Committed.
You can only remove an inherited state that's been hidden.
Under Rules, create the following rule.
- Name: Assign Active
- When: A work item stage changes to . . . Active
- Then: Use the current user to set the value of . . . Assigned To
Return to the Work Item Types and disable Product Backlog Item
Only disable PBI if you are not going to apply the new process to an existing project. If you are, leave PBI enabled so that you can change existing work items from PBI to Story.
Open Bug and make these changes.
- Hide System Info, Acceptance Criteria, Priority, and Activity.
- Optional: I hide the Build fields
- Add More Info, Developer Notes, Testing Notes, Reported By, and Blocked
Any fields added to Story will be in the "Use existing field" dropdown.
Treat Bugs as a defects reported by production users. Why? Because it makes it much easier to track Bug fix cycle time. See below for tracking defects during development.
Under States, add Active to In Progress, hide Approved and Committed
Under Rules, create the same Assign Active rule as in Story
Pre-Release vs Post-Release Defects/Bugs
If your shop includes quality assurance, user-acceptance testing, or other non-unit testing, you should track your defects separately from Bugs. If those roles are in your team, then I like communicating those defects at the same level as Tasks. If they're outside the team, then I recommend tracking them at the same level as Bugs.
- Create a new work item type named PreRelease Defect with the same fields, states, and rule as Bug. Hide Description. Choose an icon you like.
OK, the work items are ready!
These changes make your new work item type availabe in the New item dropdowns on boards and backlogs.
- Open SimpleSrum > Backlog levels
- Edit Backlog items and add Story and PreRelease Defect. Set Default work item type to Story
Use the Process
You can create a new Project using the SimpleScrum process, but you can also apply the process to an existing project.
Applying a process does come with risks if there are non-matching fields. Be sure you read the documentation!
I'm going to apply the process to Baskets-R-Us (from Part 1 of the series) so you see what's involved and why starting with a new project might be better.
Open All Process and click the Scurm Team Projects link
For BRUW, select Change Process and choose SimpleScrum
Fix up the work items
Open the BRUW project > Queries > New Query
Return all work items
Open Column Options and add State and Reason. Sort by Work Item Type and State
Select all Product Backlog Items, right-click > Change Type, select Story.
Select Commmitted items, right-click > Edit, change State to Active
Select Approved items, right-click > Edit, change State to New
You may have other changes to make to your work items.
Fix up the Story Board
Story Board customizations are at the Team level
Open the BRUW project > Boards. I was greeted with this message:
Fine, I'll Correct this now. It's the board's column settings that need changing, which is what I want to do anyway!
You can't delete any columns that have stories in them until you move the stories.
- Keep all existing columns. Rename Ready for QA to Ready for Test, QA to Test. Map each column's state to Active for now. Save.
- Clear all filters. Move stories out of Approved, Ready for Dev and Ready for Release
- Remove columns Approved, Ready for Dev and Ready for Release.
Open the board's Settings > Styles, add a styling rule
- Name: Blocked
- Card color: Red
- Rule criteria: Blocked = Yes
If a Story's Blocked field is set to Yes, the card will show red.
Fix up the Task Board
Task Board customizations are at the Team level
- Open the Task Board (Sprints) Settings
- In Fields > Story, add a field to always show Parent. This lets you see a story's Feature if it has one.
- Add a Styles rule for Blocked as done above
What about work item templates?
Azure DevOps supports templates, and I wish they were useful. Maybe they will be for you, but what I want is to assign a default template to a work item for my team. For example, have a Bug template with starter info in Repro Steps that's automatically applied on any new Bug.
Until that happens, I'll leave you with Microsoft's documentation.
Use work item templates to update stories & more - Azure Boards | Microsoft Docs
This post sets up a good, basic process. A key aspect is that work items at the same level are structured almost the same. This helps reduce cognitive friction switching from a Bug to a PreRelease Defect to a Story, and emphasizes that the primary difference between them is their name.
As one Scrum consultant I heard interviewed put it, "I think of every work item as a story."
In the next post, we'll put this process to work.