Looking for some Azure DevOps Board best practices

[RohitKumar]

I am looking for some Azure DevOps Board best practices regarding releases, backlogs, and teams. We did a massive shift to Boards this year, and Iterations/Sprint & Backlog settings have been a point of confusions when rolling from release to release.

[MichaelYoffe]

Hi @Rohit, my team is using Azure Devops right now (although some of the settings are organization mandated) What particular questions did you have?

[RohitKumar]

Thanks @Michael. On team, the Iterations for Default and Backlog appear to provide very different behaviors when moving from a releases iterations. Each of our teams are fumbling with this as we hit our release timelines.

[MichaelYoffe]

There’s only so much I can show given confidentiality concerns, but I think I can show you how our Board is set up in this case without giving away any trade secrets.
Here’s a screen shot of how my team’s iteration is set up.

[MichaelYoffe]

I should say that the Project0 holds all of the teams at my clients organization and HedgeHogs is my team. There were some annoyances with having every team report up through the same Project, but we were much more irritated with those things a year ago than we are now.

So much so that I forgot what the irritation was.

We then create Iterations as a subset of HedgeHogs, and that seems to work fairly well for us.

Note that we used the same structure for Default as we dd Backlog. So when I create an item, it gets assigned to Project0/HedgeHogs which is what our board uses to show items. When we actively include an item in a sprint, we move it to a specific sprint.
Not sure if that helps or not…

[RohitKumar]

Thanks. Our Hedgehogs has a release iteration level below. Hedgehogs\11.5… which we carry into the default and backlog iteration above on one team, but then Sonic does to without the 11.5 in the backlog.

[MichaelYoffe]

I think you may be running into difficulty trying to incorporate the concept of a release into your iteration structure (This is a weakness of SAFe and their PSI in my opinion).
We’ve had pretty good luck just letting our iterations act as time boxes, and we identify release content by attributing pull requests to a specific work item, and then let Azure Devops do the tracking of what work items were satisfied with a specific code promotion (which are labeled as releases in the pipeline section of Azure DevOps)

[RohitKumar]

Thanks Michael. The team that is struggling is one that used Boards but not git/pipeline/etc.

[MichaelYoffe]

Ahh… one key observation about Azure Devops is that it’s value is that it pulls all those disparate things together even though it doesn’t do any of those things very well individually.
Meaning I’ve found other tools that seem to manage backlogs better, but there is value in having the backlog tied in directly to source code control for the reasons I mentioned above.