Что означает, что PBI должен быть зафиксирован во время отставания в MSF Scrum 2.2?

Пытаясь понять, что я вижу в TFS 2012 Web Access в разделе WORK | отставание | Backlog продукта, я использовал кнопку "Create Backlog Query", а затем открыл новый запрос в редактировании, чтобы увидеть, как он работает. Я заметил, что он отображает PBI, которые соответствуют двум описаниям:

• PBI в любом месте под итерацией корня (backlog) в состоянии New/Approved.
• PBI в отставании (итерация корня) в состоянии New/Approved/Committed.

Почему PBI соответствует этому второму описанию? Почему PBI когда-либо был зафиксирован в отставании? Может быть, это какой-то способ сохранения theme- или PBI на эпическом уровне после уточнения и установки их для совершения, когда их дети на уровне пользовательского уровня привязаны к реальным спринтам? Может быть, это просто средство для компенсации дрянной бухгалтерии, когда неполные PBI выбиваются на отставание, но не возвращая свои штаты обратно в Approved? Может быть, другая причина?

Ответы

Ответ 1

Новое. Это PBI, которые кто-то добавил в отставание продукта и не были просмотрены владельцем продукта и не были согласованы с ним.

Утверждено - это PBI, с которыми согласился владелец продукта, отредактировал и убедился, что они понятны для команды. После утверждения они готовы к команде, чтобы забрать в планировании спринта.

Committed - команда Scrum обсудила PBI в планировании спринта, создала некоторые задачи и согласилась построить PBI в текущем спринте.

Выполнено. В обзоре спринта владелец продукта проверяет работу, выполненную командой, и если он/она согласен с тем, что он соответствует требованиям и стандартам качества, тогда элемент перемещается на выполнение.

Ответ 2

Ты прав! С точки зрения SCRUM нет смысла перечислять Committed PBI в отставании. Команда либо передала PBI на спринт, либо нет.

Интересно, что термин Committed не упоминается в Руководстве SCRUM для планирования Sprint или Sprint Backlog.

Мое предположение - Microsoft использовала термин " Committed чтобы описать принадлежность команды разработчиков к PBI при перемещении из Product Backlog в Sprint, но не захотелось принудить к правилу посредством проверки или автоматического изменения статуса PBI.

Если вы ищете более авторитетный источник - в MSDN есть статья диаграммы состояний, которая описывает доступные статусные точки без реферирования Sprints.