스프린트 동안 스프린트 백 로그 수정에 대해 혼란


14

나는 최근에 스크럼에 대해 많은 것을 읽었으며 스프린트 중에 스프린트 백 로그를 변경해도 괜찮은지에 대한 정보가 상충되는 것으로 나타났습니다. 스크럼에 대한 위키 백과의 문서 는 확인하지, 그리고 다양한 말한다 다른 기사 뿐만 아니라이 말을. 또한 저의 소프트웨어 개발 교수는 스크럼 개요에서 같은 것을 가르쳤습니다.

그러나 트렌치에서 Scrum 및 XP를 읽었 으며 작업 보드의 계획되지 않은 항목에 대한 섹션을 설명합니다. 그래서 저는 스크럼 안내서를 찾아보고 스프린트 중에 "스프린트 목표에 영향을 미치는 변경 사항이 없습니다"와 스프린트 목표에 대한 논의에서 "개발팀이 예상 한 것과 다른 경우, 그런 다음 제품 소유자와 협력하여 Sprint 내에서 Sprint 백 로그의 범위를 협상합니다. " 스프린트 백 로그 (Sprint Backlog)에 대한 논의에서 계속됩니다.

스프린트 백로 그는 진행중인 변경 사항을 일일 스크럼에서 이해할 수 있도록 충분히 상세하게 계획된 계획입니다. 개발팀은 스프린트 전반에 걸쳐 스프린트 백 로그를 수정하고 스프린트 동안 스프린트 백 로그가 나타납니다. 개발 팀이 계획을 진행하면서 스프린트 목표를 달성하는 데 필요한 작업에 대해 더 많이 알게되면 이러한 출현이 발생합니다.

새로운 작업이 필요할 때 개발팀은이를 스프린트 백 로그에 추가합니다. 작업이 수행되거나 완료되면 남은 예상 작업이 업데이트됩니다. 계획의 요소가 불필요한 것으로 간주되면 제거됩니다. 스프린트 동안 개발팀 만이 스프린트 백 로그를 변경할 수 있습니다. 스프린트 백로 그는 개발 팀이 스프린트 동안 달성 할 계획 인 작업에 대한 가시적 인 실시간 그림으로, 개발 팀에만 속합니다.

그래서이 시점에서 나는 완전히 혼란스러워합니다. 그것에 대해 생각하면 두 번째 접근법을 취하는 것이 더 합리적입니다. 백 로그의 개별적이고 구체적인 항목은 가장 중요한 것이 아니라 스프린트 목표 인 것처럼 보이며 스프린트 목표를 변경하지 않고 백 로그를 변경할 수 있다는 것이 합리적입니다. 예를 들어, 제품 소유자와 팀이 스토리에 대해 같은 페이지에 있다고 생각했지만 스프린트가 진행되면서 오해가 있음을 알아 차리고 그에 따라 해당 스토리를 구성하는 작업을 변경하는 것이 합리적입니다. . 또는 잊혀진 스토리 나 작업이 있지만 스프린트 목표에 도달해야하는 경우 스프린트 중에 스토리 또는 작업을 백 로그에 추가하는 것이 가장 좋습니다.

그러나 스프린트 백 로그에 대한 변경이 괜찮지 않다는 상당히 단호한 것처럼 보이는 사람들이 많이 있습니다. 어떻게 든 그 위치를 오해하고 있습니까? 스프린트 백 로그를 정의하는 사람들은 어떻게 다른가? 스프린트 백 로그에 대한 나의 이해는 그것이 스토리와 그들이 분류 한 작업으로 구성된다는 것입니다.

어쨌든이 문제에 대한 의견을 보내 주셔서 감사합니다. 스프린트 동안 스프린트 백 로그를 변경하는 이상적인 이론적 스크럼 접근 방식과 개발에 스크럼을 성공적으로 사용하는 사람들이 스프린트 동안 스프린트 백 로그를 변경할 수 있는지 여부를 모두 파악하려고합니다.

답변:


10

우선 나는 그것에 대해 엄격한 규칙을 갖지 않을 것입니다. 스크럼의 요점은 상황에 적응할 수 있도록하는 것입니다. 따라서 중요한 것을 잊어 버린 것처럼 스프린트 중에 스프린트 백 로그를 수정할 수 있어야합니다.

그러나 스프린트 동안 스프린트 백 로그에 대한 이러한 수정은 저항해야한다. 스프린트의 짧은 요점은 전체 프로젝트 타임 라인 (여러 스프린트)에 영향을주지 않고 다음 스프린트에 새로운 작업을 추가 할 수 있다는 것입니다.

그러나이 스프린트의 작업 중 하나에 대한 작업이 중요한 경우 두 가지 옵션이 있습니다.

  1. 스프린트에 새 항목을 추가하십시오.
    그러나 스프린트에서 동등한 크기의 항목을 제거하십시오.
  2. 이 스프린트에서 잘못 계획된 항목을 삭제하십시오 (따라서 다음 스프린트에서 올바르게 계획 할 수 있습니다).
    • 제품 백 로그 상단에서 적절한 크기의 대안을 추가합니다 (스프린트 계획 미팅에서 우선 순위를 정해야 함).
    • 또는 모든 스프린트 항목이 완료되면 개발자가 제품 백 로그에서 느슨해지지 않도록하십시오.

그래서 나는 당신이 아마 스프린트 백 로그를 수정해서는 안되는 캠프에 있습니다. 그러나 예외적 인 상황이있을 수있는 상황을 고려해야합니다. 대부분의 경우 옵션 2를 사용하여 개발자가 백 로그에서 작업으로 여유를 갖도록 할 것입니다.

다음 계획 회의에서 새 작업이 적절하게 분석되고 스프린트에 추가됩니다 (적절한 경우).

스프린트는 짧고 개발주기의 끝이 아니라 다음 드롭의 표시 만 기억하십시오. 제품 소유자는 다음 스프린트가 끝날 때까지 기다릴 수없는 기능에 대해 필사적이어야합니다.


단순히 오해가 있었을 경우 어떻게해야합니까? 예를 들어 팀은 품목의 크기가 거의 같다고 가정 할 때 제품 소유자가 다른 것을 의미한다고 생각 했습니까? 이것은 실제로 내 작업에서 일어났기 때문에 순수한 이론적 질문은 아닙니다.
Maltiriel

3
Loki가 응답 한 내용을 추가하려면; Sprint 백 로그의 변경 사항에 대해서는 제품 소유자와 논의해야합니다. 팀은 작업을 수행하기 위해 PO에 전념했기 때문입니다. 그리고 이야기가 잘못 이해되면 문제와 비즈니스 가치를 더 잘 설명하기 위해 이야기를 수정할 수 있으며, 충분히 변경되면 크기를 조정할 수도 있습니다. 그러나 항상 제품 소유자와 논의하십시오.
David '대머리 생강'

10

혼란은 모호한 언어 때문입니다.

스프린트 백 로그에는 두 가지 세부 수준이 있습니다. 첫째, 팀이 제공하기로 약속 한 항목 (사용자 사례) 목록입니다. 둘째, 팀이 각 스토리를 전달하기 위해 수행하려는 모든 작업입니다.

사람들이 스프린트 백 로그에 대해 이야기 할 때, 그들이 의미하는 바에 대해 분명해야합니다. 스크럼 안내서를 읽으면 다음과 같이 표시됩니다. 스프린트 백로 그는 스프린트 용으로 선택된 제품 백 로그 항목 세트와 제품 증분 제공 및 스프린트 목표 실현 계획입니다.

따라서 제품 백 로그 항목 목록과이를 제공하는 계획 (작업)입니다.

이제 많은 팀이 스프린트 시작 부분에 제안 된 모든 작업 (계획)을 추가하여 남은 시간을 기준으로 번 다운 차트를 추적 할 수 있습니다. 다른 팀은 필요에 따라 작업을 수행 할 수 있습니다. 팀이 아이템을 전달하고 스프린트 목표를 달성하기 위해 검사하고 조정하기 위해이를 수행해야하기 때문에 '스프린트 백 로그'에 추가해도됩니다.

특정 상황에서 팀은 일정을 앞두고있을 수 있으며 (팀의 기능을 향상시킬 수있는 다른 유용한 작업을 모두 제거한 경우) 제품 담당자와 협력하여 제품 백 로그 ...하지만 해당 스프린트 내에서 완료되고 스프린트 목표와 일치 할 것이라는 확신이있는 경우에만 해당됩니다.

그래서 우리는 그것을 가지고 있습니다. 예 ... 팀은 필요에 따라 스프린트 백 로그 계획에 작업을 추가합니다. 아니요, 일반적으로 스프린트 범위를 정의하는 백 로그 항목 목록에 추가되지 않습니다.

이것이 상황을 분명히하기를 바랍니다.


1
흠, 그것은 특히 사람들이 이야기 / 항목 대 작업에 대해 명확하지 않은 것에 대한 당신의 요점을 돕습니다. 그러나 팀과 제품 소유자 간의 오해와 같은 새로운 작업 추가뿐만 아니라 작업 변경 / 대체에 대해서도 궁금했습니다. 나는 그에 대한 "모범 사례"가 무엇인지 말할 수 없었기 때문에 그것에 대한 의견이 있다면 감사하겠습니다.
Maltiriel

2

상황에 따라 다릅니다. 계획 중에 일부 정보가 누락 된 다음 나중에 몇 가지 이야기에 포인트를 수정하거나 추가해야한다는 것을 알게되면 괜찮습니다. 그러나 기능의 범위가 완전히 바뀌면 극단적 인 상황이므로 다르게 처리해야합니다.

물론 계획 중에는 모든 사람이 작업 할 각 기능에 대해 명확하게 알고 토론하는 것으로 가정합니다. 토론과 계획이 좋으면 거의 모든 경우에 실제로 수정이 필요하지 않습니다.


"계획하는 동안 모든 사람들이 자신이 작업 할 각 기능에 대해 명확하게 알고 토론하는 것으로 가정합니다."물론 일반적으로 모든 것이 해결되지만 관련된 모든 사람은 인간이므로 때때로 일이 균열로 빠져 나갑니다. 많은 사람들이 스프린트 백 로그를 어떤 상황에서도 스프린트 동안 전혀 편집 할 수 없을 정도로 단호하게 보이기 때문에 내가 궁금해했던 사례입니다.
Maltiriel

:) 그렇습니다 우리는 인간입니다. 때로는 스프린트 중에 변경해야합니다. 그러나 계속 반복해서 발생하면 다른 문제가 있습니다. 이것에 대해 모든 사람에게 이야기하고 상호 합의 된 해결책을 생각해보십시오.
Kumar Bibek

0

나는 대답에 동의합니다. 이야기가 개발을 시작하면 끝날 때까지 멈출 수 없다는 것을 지적합니다.

일찍 발 뒤꿈치를 파십시오. 변화를 요구하는 사람들은 어려운 방법을 배워야합니다. 그렇지 않으면 사람들이 당신이 어쨌든 원하는 것을 할 수 있다는 것을 배우면 무가치 한 계획을 세우게됩니다.

품질은 초점에서 비롯되고 버그는 많은 생각을 버리는 데서 비롯됩니다. 컨텍스트 전환 비용을 인용하십시오. 빚을 추적하고 반 구운 일을 처리하기 위해 이야기를 쓰고 토론하고 재생하는 것은 비용이 많이 듭니다. 이 경로를 시작하지 마십시오.

아이디어 : 경영진에게 분기마다 타협으로 사용할 수있는 3 개의 스위치 크레딧을 제공하십시오.


"나는 그 대답에 동의한다. 만약 이야기가 개발을 시작했다면 끝날 때까지 그 이야기를 멈출 수 없다"고 지적했다. - 그건 사실이 아니야. 팀은 스토리 아이템을 끝내지 않기로 결정할 수 있습니다. 다음 스프린트에 대한 스프린트 계획이 시작되면, 그 스프린트를 다음 스프린트로 끌어 올릴 필요가 없습니다. :하지만 나는이 문처럼 정말로 "품질이 초점에서 오는 버그가 생각의 기차를 삭제 출신"
브라이언 오클리
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.