Я думаю, вы понимаете разницу между Заинтересованным лицом и Базовым (также по подписке) уровнями доступа пользователей, поэтому я собираюсь пропустить любой из этихобъяснение.
Я понимаю, что вы хотите, чтобы одна группа участников не смогла изменить резерв, а другая группа была допущена, но тем, кому это запрещено, все еще нужно редактировать другие части рабочих элементов (т. е. состояние)
Вот варианты, которые я вижу, чтобы получить что-то вроде того, что вы хотите:
TL; DR Трудно получить то, что вы ищете.
Вариант 1
Проявите творческий подход к тому, как ваш процесс обрабатывает области.
Вы можете создать узел области для рабочих элементов, чтобы получать их приоритет от Владельцев продукта, и подчиненный узел для разработчиков на самом деле.на предметы.Это не красиво, потому что теперь, когда вы загружаете спринт, вы не просто перетаскиваете с одного пути итерации на другой, но вы также изменяете путь области, чтобы у группы разработчиков было разрешение на обновление рабочих элементов..
Насколько я понимаю, когда вы перемещаете предметы из области определения приоритетов, разработчикам по-прежнему будет разрешено перемещать вещи (читай: расставить приоритеты) на своей доске объявлений / невыполненных работах.Однако единственной работой, которая должна быть в этой области, является работа, запланированная для предстоящей или текущей итерации, и в этот момент приоритет не должен иметь большого значения, поскольку ожидается, что все это будет выполнено к концу спринта. Но , если отставание разработчика имеет спецификацию области, которая включает в себя ограниченный узел, эти элементы все равно будут отображаться в очереди с другими элементами, которые не находятся в ограниченной области.Разработчик все еще может перемещать неограниченный предмет над ограниченным предметом, не изменяя значение ранга стека ограниченного предмета.Неограниченный элемент находит значение, которое подходит для его новой позиции.
Вариант 2
Создайте новый проект, единственная цель которого состоит в том, чтобы обеспечить порядок в бэклоге (ах).Ваши ПО будут в этом проекте, а ваши разработчики - в другом.При планировании спринта (или любой другой церемонии приема, на которую вы подписываетесь) вы будете вытягивать приоритетные предметы из одного проекта в другой.
Здесь применяется то же предупреждение, что и в варианте 1.
Вариант 3
Организуйте свои уровни Backlog (с соответствующими элементами) таким образом, чтобы вашей команде по определению приоритетов нужно было только расставлять приоритеты для типов элементов портфеля невыполненных заказов,и ваша команда разработчиков может создавать / расставлять приоритеты по своим рабочим элементам требований и уровня итерации, как они считают нужным, основываясь на том, как выглядят их спринты.
Здесь применяется то же предостережение, что и в вариантах 1 и 2, но при аренде ваши разработчики будут иметь больше визуального представления о том, что они работают с неправильным отставанием и не должны возиться.
Заключение
Ни один из этих вариантов не является наилучшим вариантом для именно того, что вы хотите, и вам может быть проще и проще управлять разработчиками, которые перемещают рабочие элементы из своего приоритета, постоянно применяя соглашениеи упрекать тех, кто не следует за ним.