In 2014, the Scrum Guide was moved off of Scrum.org and posted to ScrumGuides.org. At the same time, all of the major Scrum organizations in the world acknowledged this as the official definition of Scrum. Unfortunately, Microsoft still hasn’t received the memo.
Sure, they have a Scrum process template and it was quite good (back in 2010) because it was very minimal – “barely sufficient” even. Unfortunately, as the Scrum guide evolved, the template did not. What’s worse, Microsoft decided that we all wanted Scaled Agile Framework (SAFe) support in all templates. Our once-very-lean Scrum process template has wandered away from the light and become bloated with waste – no longer “barely sufficient”.
Fortunately, there are several Professional Scrum Developer Trainers (Visual Studio ALM experts who also teach Scrum, and vice versa) who have offered to help. This is our unordered backlog:
Scrum Process Template
- Remove Priority and Value Area from the PBI work item type
- Remove Priority, Severity, Activity, and Remaining Work fields from the Bug work item type
- Remove Priority and Activity fields from the Task work item type
- Remove Priority from the Impediment work item type
- Remove Epic and Feature work item types and just use PBI (or just “Item”) work item type at all levels
- Let the teams provide the names for the backlog levels
- Change Committed > Forecasted state in the PBI and Bug work item type
- Hide the Reason field in all work item types
- Change Effort > Size in PBI and Bug work item types
- Add Business Value to the Bug work item type
- Use the @CurrentIteration query token in default queries
- Change label Assigned to > Owned by
- Make Scrum the default process template (it used to be)
We know that Microsoft supports custom process templates, which is great and provides Microsoft and its customers a vehicle to still deliver bloated process templates to the market.
Agile Planning Tools
- Show PBI work item types on all backlog levels, letting the team decide how many and provide names of those levels (don’t assume Epic, Feature, and PBI)
- Remove/hide Capacity Planning tools (or at least disable planning by individual/discipline)
- Fix Forecast tool (don’t assume we’ll start work in one sprint and finish the next; also show Sprints even though they aren’t defined yet)
- Let me specify which user is the “Product Owner” and “Scrum Master” to help auto-assign work items, tweak views, etc.
- Provide first class support for a definition of “Done”
- Provide first class support for Sprint goals
- Provide first class support for Sprint Retrospective improvements
- Let me pivot the board by something other than state (e.g. effort/size – Fibonacci, team, area, iteration, business value – Fibonacci)
- Enable computed columns in the backlog (e.g. ROI = business value / effort/size)
- Provide a burndown chart by PBI/Bug/Testing results (not just tasks/task hours)
- Provide a burnup chart by business value
Add Scaling Support
- Provide first class support for teams (don’t rely on Area path)
- Show me an aggregate board of all teams’ Sprint Backlogs (PBI and Bug work items) and any dependencies across the items/teams
- Show me an aggregate board of all teams’ selected PBI and Bug work items and any dependencies across the items/teams with Sprint +1, Sprint +2, … Sprint +n columns
Most importantly, please adopt a lean thinking approach to the features you deliver in the future. I’m not saying “check with the PSD community” before adding or changing anything in the agile planning tools, but please take a sniff (or ask us to) and see if there is a smell that your shiny new tool idea wanders away from making VSTS/TFS “barely sufficient” or hinders “individuals and interactions”.
