PBI 대 사용자 스토리

최근에 제품 소유자가 "x 페이지에서 로그인 페이지로 이동하면 오류가 표시됩니다. 해당 오류를 제거하고 싶습니다"라는 항목이 제품 백 로그에 추가되었습니다.

이것은 유스 케이스가 아니며 PBI (Product Backlog Item)가되어서는 안됩니다. 그러나 내가 토론했을 때, 스크럼 마스터는 사용자 스토리는 PBI가 아니며 PBI는 버그 보고서, 작업, 사용자 스토리, 무엇이든 말 그대로 먼저 해결해야 할 항목 일 수 있다고 말했습니다.

확실하지 않습니다. 또한 웹 에서 PBI 에 대한 좋은 정의를 찾을 수 없습니다 . 제 질문은 제품 백 로그에 어떤 종류의 물건 을 항목으로 넣을 수 있습니까? 제품 백 로그 항목이 사용자 스토리에 맵핑됩니까? 그들은 같은가요?

제품 백 로그 항목이 사용자 스토리에 맵핑됩니까? 그들은 같은가요?

반드시 그런 것은 아니지만 일반적으로 그렇게합니다. 스크럼 마스터가 말했듯이 다른 것들도 제품 백 로그 항목이 될 수 있습니다. 그러나,이 방법에 따라 달라집니다 당신의 스크럼 작동합니다. 일부 팀에는 스프린트에 대해 고려되는 별도의 버그 백 로그가 있으며 다른 팀은 제품 백 로그에 이러한 사항을 유지합니다.

두 개의 별도 로그를 사용하면 다음 스프린트를 위해 두 개의 로그를 고려해야하므로 제품 소유자가 작업의 우선 순위를 결정하기가 더 어려워집니다. 그러나 그들은 더 나은 감독을 제공하며 둘 다 개별적으로 우선 순위를 지정할 수 있습니다.

그래서 제 질문은 어떤 종류의 것들이 제품 백 로그에 아이템으로 들어갈 수 있습니까?

이는 제품 비전의 일부이며 만들려는 제품으로의 여정 일 수 있습니다. 여기에는 대부분 요구 사항 (사용자 사례)이 포함되지만 제품에 직접 속해 있지 않은 작업이나 기술적 인 내용도 포함 할 수 있습니다 (예 : "개발팀을위한 새 서버 구매", "제품에 대한 광고 만들기"). 백로 그는 불필요한 세부 사항을 피해야하며 기술적 사항을 미세 관리하려고 시도해서는 안됩니다. 제품 백 로그에는 제품에 가치를 제공하는 모든 것이 포함될 수 있습니다.

진정한 스크럼은 없습니다. 때로는 별도의 백 로그가 제품을 관리하는 더 좋은 방법 일 수 있으며 때로는 방해가됩니다. 무엇이 가장 적합한 지 알아보십시오.

버그에 대해 작업 할 때 백 로그에 버그를 추가하고 버그 스토리 라고합니다 . 이러한 방식으로 백 로그에 버그 수정을 추가하면 버그 수정 만이 아니라는 것이 분명합니다. 자동화 된 테스트가 작성되고 확인이 완료되도록 다른 작업을 추가 할 수 있습니다. 또한 DoD를 준수해야한다는 것을보다 명확하게합니다.

우리는 백 로그 도구가 PBI라는 용어를 사용한 적이 없지만 항상 사용자 스토리, 버그 스토리 또는 단순히 스토리 입니다.

주로 팀에서 선택한 용어 일 뿐이며 실제로 중요하지 않은 것이 무엇인지 분명한 한 말입니다.

위의 모든 답변은 Scrum 프레임 워크에 대한 신뢰할 수있는 소스 문서 : Scrum Guide 를 참조하지 않습니다 .

제품 백 로그

제품 백 로그 및 그 안에 포함 된 항목 (일반적으로 PBI라고 함)을 설명하는 섹션이 있습니다.

제품 백 로그에는 향후 릴리스에서 제품에 대한 변경 사항을 구성하는 모든 기능, 기능, 요구 사항, 개선 사항 및 수정 사항이 나와 있습니다.

그러나 프로젝트 계획처럼 고정되어 있지 않습니다 .

제품 백로 그는 제품과 사용 환경이 발전함에 따라 발전합니다. 제품 백로 그는 동적입니다. 제품이 적절하고 경쟁력 있고 유용해야하는 것을 식별하기 위해 지속적으로 변경됩니다.

사용자 스토리

사용자 스토리 라는 용어 는 Scrum Guide에 나타나지 않습니다.

다양한 프로세스와 기술을 사용할 수있는 프레임 워크입니다.

사용자 스토리를 사용하는 것은 PBI를 기록 할 수있는 기술 중 하나 일뿐입니다.

또한 "As, I want, So that"형식을 보는 것이 일반적이지만, 원래 의도에 반할 수 있습니다 . 이 번거로운 형식은 Agile 2017 에서도 해결되었습니다 .

@Falcon이 잘 설명했습니다. 공식적으로 정의 된 한 페이지는 다음과 같습니다. http://en.wikipedia.org/wiki/Scrum_(development)#Product_backlog 설명하신 내용은 최소한 해당 설명에 따라 제품 백 로그에 배치해서는 안됩니다.

제품 백 로그에는 사용자 스토리 만 허용된다는 일반적인 오해가 있습니다. 반대로 스크럼은 요구 기술에 중립적입니다. 현상태대로 스크럼 프라이머 상태,

제품 잔고 품목은 명확하고 지속 가능한 방식으로 명료하게 표현됩니다. 널리 알려진 오해와 달리 제품 백 로그에는 "사용자 사례"가 포함되어 있지 않습니다. 그것은 단순히 항목을 포함합니다. 이러한 항목은 사용자 사례, 사용 사례 또는 그룹이 유용하다고 생각하는 기타 요구 사항 접근 방식으로 표현할 수 있습니다. 그러나 어떤 접근 방식이든 대부분의 품목은 고객에게 가치를 제공하는 데 중점을 두어야합니다. *

• 제품에 대한 변경 및 추가 사항에 대한 명확한 사양을 제품 백 로그 항목 (PBI)이라고하며 제품 백 로그를 구성합니다.
• 각 PBI는 개발자가 완료시 관련 이해 관계자에게 가치를 부가하기 위해 개발하고 제공 할 수있는 것을 설명합니다 (완료 정의 참조).
• 가장 일반적인 이해 관계자는 시장 또는 그 대표자 인 제품 소유자입니다.
• 그러나 PBI는 기업에 대한 비용을 줄이거 나 개발 팀의 노력을 줄이는 작업 또는 제품 소유자 팀이 작업을 더 잘 수행하는 데 도움이되는 도구를 설명 할 수 있습니다.
• PBI는 이해 관계자에게 잠재적 가치가있는 모든 것을 설명 할 수 있습니다.

(사용자) 스토리는 백 로그 항목에 유용한 표준 형식입니다. 배후의 근거는 "아무도 신경 쓰지 않으면 시간을 낭비하지 마십시오"입니다. 또한 PO는 아이템의 긴급 성을 평가할 수있게 해주므로, 누가 무엇을할지, 얼마나 나쁜지를 정의하기 때문입니다.

귀하의 경우 버그는 이야기로 쉽게 형식화 될 수 있습니다.

• 사용자로서
• X 페이지에서 로그온하고 싶습니다 (대신 오류가 발생하지 않음)
• 그래서 나는 시간을 잃지 않을 것이며, 제품에 대한 화가 믿지 않을 것입니다

노력할만한 가치가있는 것 같습니다.