0

I am looking for a way to configure TFS to enforce triaging of PBIs and bugs. At present, although "proper" practises have been discussed and agreed many times, they are not followed reliably, so I am looking for a way to enforce them via TFS configuration and security.

In our organisation, a large number of people across a number of departments (Sales, Project Management, Support, Operations, Development and Testing) needs to have some say in the development of our products. Within these groups there are designated Product Owners for each product.

Many years ago we agreed to follow a Scrum-like model for development work. Put very simply we agreed:

  • Developers are assigned to teams. Each team manages a number of products (there are too many products to have 1 team per product).
  • There is one separate team called "Management", which is intended for new PBIs and bugs, i.e. triaging before rejecting/moving to a development team. This team has a backlog but no sprints.
  • Anyone who has a stake in a product can raise a PBI or Bug, but it must be raised inside the Management team backlog
  • The Management team backlog is reviewed regularly and if OK'd PBIs and bugs are moved to a development team backlog, and then to a sprint

Unfortunately however, this process is not followed reliably. PBIs and bugs are posted directly into development team backlogs, or worse, into sprints. The quality of the information is often very poor. In other words, triaging is bypassed.

So now I am looking for a way to completely block PBIs and bugs from being posted or moved into development teams, except by designated people (e.g. team leaders). In other words, everyone else can only post into the Management team backlog.

However, TFS does not seem to support permissions by iteration (i.e. on backlogs or sprints). Within a single project, if someone is allowed to post, they can post anywhere. It is possible to restrict posting by Area Path, however we use Area Path to capture the related product ... I could re-purpose this field, but would rather not.

So the question is - is there any way to block posting or moving of PBIs and Bugs into specific team backlogs and sprints?

Notes:

  • I know this could be looked at as a "people" problem. Yes, but after years of dealing with the same issue, re-agreeing processes, I have come round to the idea that "fences" need putting in place. I will not be accepting any answers along the lines of "staff training/discipline/etc needed!" or "just leave!" :)
  • we are currently on TFS 2013 on-premises, but will move to AzureDevOps 2019 on-premises
  • all teams are in a single TFS project, in other words we use the "Single Team Project" model
Laurence
  • 101
  • 1
  • Trying to solve a people problem with a technical solution will always fail. I know you don't want to hear that, but the process is what's broken. Having a say in the product doesn't mean that everyone needs access to create PBIs. The product owner should be the one triaging requests. Find another way for them to collect requests outside of your backlog and sprint. – Dan Wilson Sep 23 '20 at 21:17
  • I think there are plenty of examples of systems where the "input" end is very open, and the "output" end is far more controlled. Take projects managed in Github - anyone can fork the project and submit a pull request, but the merging of contributions is highly controlled. I also would rather have 1 system than 2 (i.e. a request collecting system which is manually fed into TFS). Anyhow, that is opinion - the question is - can this be done? – Laurence Sep 25 '20 at 08:39

0 Answers0