스프린트에서 포커를 계획하는 목적은 무엇입니까?

우리의 비즈니스 분석가 및 프로젝트 리더는 고객의 요구 사항을 스토리로 알려줍니다. 모든 스프린트 계획, 우리 (개발자)는 계획 포커를해야합니다.

그들은 우리 모두에게 '노력'보다는 '복잡성'을 고려하도록 요청했습니다. 우리는 정말로 혼란 스러우며 회의에 시간을 낭비하고 있습니다. 한 개발자가 '무엇을 정말로 고려해야합니까? 이 요구 사항 (시간 추정)에서 수행해야하는 코드 / DDL 변경에 관한 것인지 아니면 요구 사항을 이해했는지 여부에 관한 것인가? '

그러나 '비즈니스 분석가 및 프로젝트 리더'는 실제로 '요구 사항 이해'와 '카드 올리기'란 무엇을 의미합니까?

또한 개별 스크럼 팀을위한 슬라이싱 회의가 있으며, 각 개발자는 각 스크럼 팀에 대해 주어진 작업에 대한 시간을 추정합니다. 그래서 계획 포커에서 실제로 어떤 종류의 이야기를하고 있습니까?

누구나 예제를 사용하여 이것을 설명 할 수 있습니까? 그들이 '복잡성'과 '노력'이라고 말할 때 그들이 실제로 말하는 것을 차별화하십시오.

프로젝트 관리자의 관점을 고려하십시오

그들은 복잡성을 요구함으로써 다음 스프린트와 비교하여 팀으로서의 속도를 찾을 수있는 숫자를 원합니다. 또한 모든 스토리가 언제 완료 될지에 대한 전체 추정치를 제공하기 위해 다른 팀의 추정치와 결과를 합치기 위해이 정보를 사용하려고 할 수도 있습니다.

프로젝트 관리자는 프로젝트 완료 시점 또는 시간 기능 비용 삼각형의 다른 측면에서 융통성이있을 경우 남은 시간에 맞추기 위해 다른 이탈자를 끌어낼 수있는 예상치를 찾고 있습니다. 이것은 합리적이지 않습니다. 이 추정치를 바탕으로 비즈니스 결정을 내려야합니다. 문제는 소프트웨어에 대해 이것을 추정하기가 실제로 어렵다는 것입니다. 포커 계획은이 문제를 해결하는 방법 중 하나입니다. 단순히 스토리 포인트의 수를 더하는 것으로 보는 것이 아니라 가능한 한 견적, 작업, 수행 시간 측정, 반복 및 외삽의 복잡한 함수라고 생각하십시오.

토론은 숫자보다 더 중요합니다

스토리 포인팅 회의에서 가장 중요한 부분은 토론입니다. 팀의 누군가가 숫자를 제안하는 것을 확신하지 못하면 아마도 이야기를 완전히 이해하지 못하고 더 많은 토론이 필요합니다. 민첩한 선언에서 "계약 협상을 통한 고객 협업". 사용자 스토리로 작성된 계약을 지정하고 원하는대로 정확하게하지 않으면 팀이 실패했다고 말하는 것이 아니라 고객이 이해하기 전까지 고객이 실제로 원하는 것에 대해 이야기하는 것이 좋습니다.

복잡성 대 노력

복잡성 대 노력에 대한 특정 질문을 해결하기 위해 모든 사람들은 이것에 대해 다른 의견을 가지고있는 것 같습니다. 산양 염소 는 뒷면에 염소가있는 계획 포커 카드를 만들고 Agile / Scrum 세계에서 주인 Mike Cohn이 큰 포커 카드를 만드는 사람들은 복잡하지 않고 노력해야한다고 말합니다.

사람들이 추정 시간이 나쁘고, 어떤 수에 영향을 미치는 다른 요인들과 같이, 일반적으로 시간의 척도 인 것은 아닙니다 (카운터 예는 아래의 예를보십시오). 문제에 부딪쳤을 때 더 큰 숫자를 줄 수있는 압력을 줄 수 있습니다. 소프트웨어 구축이 어렵습니다. 100 번째 집을 지을 때 99 채의 집을 지었을 때 소요되는 시간을 추정 할 수 있습니다. 빌드하는 소프트웨어가 이전에 구축 한 프로그램과 동일한 경우 소프트웨어 프로젝트가 다르더라도 복사 및 붙여 넣기를 수행 할 수 있으므로 처음에는 예상하지 못한 문제가 발생합니다.

숨겨진 압력을 포함하는 시간 추정치와 마찬가지로 노력의 측정에도 문제가 있습니다. 주니어 개발자가 높은 복잡성을 추정하면 더 낮은 평가를 제공하는 다른 사람들로부터 충분히 좋지 않은 것으로 스스로 공격 할 수 있다고 생각할 수 있습니다. 이것은 당신의 추정치뿐만 아니라 팀원들에게도 해 롭습니다.

계획 포커 수는 '일수'또는 다른 시간 측정치가 아니며 두 사용자 스토리를 비교할 수있는 상대적인 측정치입니다. 새로운 팀에서 가장 먼저해야 할 일은 기준을 세우는 것입니다. 복잡성 범위의 중간에있는 하나의 사용자 스토리를 선택하고이를 범위의 중간에있는 숫자로 팀에 동의하십시오. 이제 다른 모든 사용자 스토리는이 스토리와 관련하여 번호를 매길 수 있습니다. 나는 이것이 훨씬 쉬워졌습니다.

추정 할 수없는 이유

프로젝트 관리자가 프로젝트 수행시기를 물을 때 질문하는 질문의 복잡성을 이해해야합니다. 프로그래머는 공장 근로자가 아니며, 입력 속도와 작업 시간을 곱하여 생산성을 측정 할 수 있습니다. 그들은 문제에 대한 해답을 찾아 내는데 어려움이 있습니다. 계획 포커를하면 먼저 팀에서 누가 할당 할 번호에 대한 질문에 대답 할 수 없다고 느끼는지 파악한 다음 왜 그 질문에 대답 할 수 없는지 파헤칩니다. 적어도 네 가지 이유가 있다고 생각합니다.

1. 이야기가 너무 큽니다. 더 작고 더 구체적인 사용자 사례로 분류하십시오. 각 사용자 스토리는 사용자에게 하나의 가치를 제공해야합니다. 입력-프로세스-출력 = 값.
2. 시간이 얼마나 걸리는지 또는 모든 질문을 올바르게 할 수있을만큼 충분히 문제 영역을 이해하지 못합니다. 이해 관계자 도메인 / 프로그래밍에 대해 더 많이 아는 사람들과 이야기하십시오. 이것이 가능하지 않거나 완전히 도달하지 못하면 디자인 스파이크를 사용할 수 있습니다. 제한 적이고 지정된 시간 동안 만 솔루션을 프로토 타이핑하십시오 . 프로토 타이핑 단계가 얼마나 오래 지속 될지 정의한 다음 다시 만나 새로운 이해를 공유하십시오.
3. 이해 관계자가 구체적이지 않습니다. "클라우드 구축"은 허용 가능한 사용자 사례가 아닙니다. "필요에 따라 VM을 스핀 업할 수있는 시스템을 구축하십시오"는 더 세분화되므로 더 나아지지만 여전히 100 개가 숨겨져 있으므로 시간이 얼마나 걸리는지 정확하게 예측할 수있는 수준에 있지 않습니다. 이해 관계자가 무언가를 보여줄 때까지는 찾을 수 없다는 이해 관계자의 가정에 대한 가정.
4. 마지막으로, 당신이 견적을 줄 수 있다고해도 처음에는 틀릴 것입니다. 추정은 어려운 문제이며 어려운 문제를 해결하는 가장 좋은 방법은 과학적 방법을 사용하는 것입니다. 각 팀원이 추정 한 숫자에 대한 데이터를 수집 한 다음 실제로 소요 된 시간 또는 실제로 얼마나 복잡했는지에 대한 데이터를 수집 한 다음 시간이 지남에 따라 비교합니다. 결국 과대 평가하는 사람과 과소 평가하는 사람을 느끼게되고 팀과 공유해야합니다. 사람들은 서로 더 나은 견적을 얻도록 도울 수 있습니다. 이 숫자는 추적 도구로 다시 전달되어 스토리가 얼마나 오래 걸릴지 더 잘 예측할 수 있습니다.

결론

요점은 실제로 토론이되어야한다고 생각하지만 실제로 누군가에게 숫자를 제공해야하는 경우 팀원이 어떤 팀 멤버와 어떤 순서로 스토리를 진행하는지에 관계없이 번호를 지정하십시오. 요점은 우선 순위가 지정된 백 로그에 도달하는 것이므로 올바른 순서로 작업하고 크기를 조정하여 프로젝트 관리자가 마감일 이전에 얼마나 많은 수를 수용 할 수 있는지 확인할 수 있습니다. 반복이 끝나면 중지하고 시작된 모든 기능이 완료된 상태로 제공 할 수 있어야합니다.

경고

숫자를 자신이 유지하는 한 원하는만큼 팀 내에서 작업을 완료하는 데 걸리는 시간을 예상 할 수 있습니다. 어떤 숫자라도 팀을 벗어나 다른 사람들이 볼 수 있도록 허용하면 의도하지 않은 숫자로 작업을 수행합니다. 작업을 완료하기 위해 며칠 동안 사용하려고합니다. 그들은 당신을 상대적인 복잡도 등급으로 유지하려고 노력할 것이고 같은 수의 포인트를 가진 다른 사용자보다 한 사용자 스토리를 완료하는 데 왜 더 오래 걸 렸는지 묻습니다. 그들은 당신의 숫자를 합산하여 다른 팀의 숫자와 비교하고 다른 팀이 일정 기간 내에 더 많은 스토리 포인트를 완성하면서 왜 더 많은 일을하고 있는지 묻습니다. 넌 할 수있어

곁에

계획 포커 숫자 세트는 일반적으로 숫자 사이의 간격이 계속 커지도록 분배됩니다. 나는 이것이 사용자 스토리가 16 또는 17인지 논쟁하는 것을 막기위한 것이라고 생각합니다 .13보다 큰 경우에는 20으로 만드십시오.

예

포커 계획을 위해 숫자 1, 2, 3 및 4 만 사용하는 팀이 하나 이상 있다는 것을 알고 있습니다. 그것들은 관습에 반하고 위의 논의와 반대로, 프로그래밍 일로 정의합니다 (실제로 프로그래밍 일을 결합합니다. 즉, 두 명의 프로그래머가 동일한 머신에서 함께 작업하여 사용자 스토리를 완료하는 데 걸리는 시간입니다). 팀이 사용자 스토리를 완료하는 데 4 일 이상이 소요될 것이라고 생각하면 스토리가 아닌 상태로 유지되며 제품 소유자는 팀과 협력하여 스토리를 더 세분화하거나 더 정확하게 지정하여 스토리를 작성할 수 있습니다. 향후 계획 회의를 위해이 범위 내에 있어야합니다. 그러나 이것은 민첩한 고급 기술이며 아마도 다른 기술을 사용해 본 경험이있는 사람들 만 사용해야합니다.

나는 Frank와 Encaita의 대답이 그것을 많이 다루고 있다고 생각하지만 고려해야 할 몇 가지 추가 사항이 있습니다.

이야기 포인트를 사용하는 이유

스토리 포인트로 추정하는 목적은 응용 프로그램 기능 개발의 상대적 복잡성을 제공하는 것입니다. 그것에 대해 생각하는 간단한 방법은 다가오는 스프린트에서 예를 들어 URL 변경과 같은 이야기를 취하는 것입니다. 이것이 복잡성 측면에서 단순하다는 것을 알고 있으며 수용 기준을 명확하게 정의 했으므로 팀 전체가 1을 테스트하더라도 (Fibo 스케일 사용) 동의합니다.

다음 이야기는 사용자 데이터 집합을 집계하여 프런트 엔드에서 시각화하는 것입니다. 이제 개발자는 즉시 URL을 변경하는 것보다 훨씬 복잡하다는 것을 알고 있습니다. 당신은 이야기와 수용 기준에 대해 토론하고 많은 질문을 가지고 있으며, 이것을 할 수있는 몇 가지 가능한 해결책을 볼 수 있습니다. 다른 개발자와 QA도 매우 복잡하다는 데 동의합니다. 여러분 모두 34 점 이야기라는 데 동의합니다. Fibo 척도를 사용하면 추정치에 대한 신뢰도를 나타낼 수 있습니다. 숫자 사이의 간격이 클수록 추정치에 대한 신뢰도가 낮음을 나타냅니다.

이 시점에서 Scrum 마스터는이 이야기가 너무 커서 단일 스토리이므로 복잡성이 적은 작은 스토리로 나누어야한다고 말합니다. SPIKES로 알려진 기능을 사용하여이 방법에 접근 할 수 있습니다. 이것은 무언가를 조사하기위한 시간입니다. 따라서이 예에서 귀하와 다른 개발자는 가능한 기술 솔루션에 대해 4 시간 동안 논의하고 조사하기를 원한다는 데 동의합니다.

긴 이야기를 짧게 줄이려면 큰 이야기를 5, 8, 8 및 13 포인트의 다른 네 가지 이야기로 나눕니다. 이러한 추정치가 모두 상대적 복잡성에 관한 것임을 기억하십시오. 더 정확한 추정치를하기 위해 원래 추정치에 합산 할 필요가 없으며 더 많은 정보가 필요합니다.

그런 다음이 스프린트를 위해 13 점 스토리, 8 점 스토리 1 개 및 이미 식별 한 1 점 URL 변경을 수행하는 것을 목표로하는 팀으로 동의합니다. 총 22 점입니다. 다음 스프린트는 27 포인트를 얻습니다. 다음 스프린트는 18 포인트를 얻습니다. 스프린트 3 회 후 속도에 대한 자신감을 가지기 시작할 수 있습니다 (속도는 팀이 한 스프린트에서 수행 할 수있는 작업량입니다). 속도를 얻으려면 이전 스프린트의 평균을 취하십시오. 따라서이 예에서 평균은 (22 + 27 + 18) / 3 = 22.3이므로 Fibo 척도에서 가장 가까운 21로 반올림합니다.

이제 다음 스프린트를 위해 21 포인트를 달성하는 것을 목표로하십시오.

당신의 스토리 포인트 추정을 정확히 맞히는 데 매달리지 마십시오. 정확한 과학은 아닙니다. URL 변경은 데이터를 집계하는 것보다 훨씬 덜 복잡하므로 그에 따라 점수를 매기십시오.

또한 팀으로서 이러한 것들을 논의하는 것이 좋습니다. 스프린트 검토 중 추정치를 되돌아보고 만족하는지 여부를 논의한 후 다음 스프린트 계획 세션에 제공하십시오.

전체 팀 견적

전체 팀은 각 스토리에 대한 단일 견적에 동의해야합니다. 기능은 프로덕션 준비가 완료 될 때까지 수행되지 않습니다. 코드를 작성하는 것은 결코 끝나지 않습니다. 내 경험상 스크럼 팀은 팀으로 일할 때 훨씬 더 효과적이었습니다. 내가 지금 협력하고있는 팀의 예를 들어 보자. 내가 합류했을 때 그들은 모든 스프린트 회의를하고 포커를 계획했지만 스프린트 동안 과정은 1이었습니다. BA / 제품 소유자는 요구 사항을 합격 기준과 합격 테스트가 포함 된 스토리로 정의합니다. 2.이 요구 사항을 개발자에게 전달합니다. code 3. 개발자는 QA를 테스트하기 위해 개발 브랜치에 코드를 병합했습니다. 4. QA 테스트를하면 질문을 시작하고 테스트가 실패하여 다시 개발로 돌아갑니다.

여기서 무엇이 빠졌습니까? 사전에 충분한 토론이 없으며 각 팀원은 자신의 작업 만 보았습니다. 이제 BA / PO, 개발자 및 QA는 코드를 작성하기 전에 함께 모여 요구 사항을 자세히 논의하고 질문을 한 다음 스프린트 전반에 걸쳐 토론을 계속합니다. 이것은 훨씬 더 효율적이며 더 나은 품질의 솔루션으로 이어집니다.

부지깽이를 계획하면 팀이 기능을 논의하고 팀으로서 해당 기능을 얼마나 복잡한 방식으로 전달하는지에 동의해야하기 때문에이 프로세스에 도움이됩니다. 전통적인 소프트웨어 개발에서 프로젝트 관리자는 프로젝트 전달을 책임졌지만 그 접근 방식에 대한 경험이있는 사람은 그렇지 않은 경우가 많으므로 사람들은 응용 프로그램 전달에 대한 책임을지지 않기 때문에 작동하지 않는다는 것을 알고 있습니다. Agile에서는 팀이 애플리케이션 제공에 대한 책임을지기 때문에 프로젝트 관리자가 필요하지 않습니다.

과제의 정시 견적

스토리 포인트 만 시뮬레이션하는 작업 및 팀에 대한 시간을 추정하는 팀과 함께 일한 나의 견해는 예상하지 마십시오! 그들은 실제로 시간 낭비입니다. 그들은 팀이 아닌 개인에 따라 다르기 때문에 스토리 포인트만큼 정확하지 않으며 각 개인은 시간 추정에 대한 아이디어가 다릅니다 (불길을 가져옵니다).

스토리 포인트는 요구 사항, 항상 변경 사항을 받아들이므로 실제로 스프린트에서 팀이 완료 할 수있는 지표가 필요합니다.

속도를 이해 한 후에는 각 스프린트에서 수행 할 수있는 작업 (예 : 2 주마다 제공되는 기능을 알고 있음)을 알기 때문에 시간에 따라 산출물을 측정 할 수 있습니다. 스크럼 마스터와 제품 소유자는 향후 스프린트를 미리 예측할 수있는 평가 세션을 가지고 있어야하며 앞으로 몇 개월 동안 얼마나 많은 작업을 수행 할 것인지에 대한 지표를 얻을 수 있습니다. 이를 통해 제품 소유자는 최종 응용 프로그램에 포함 할 기능에 대해 우선 순위를 결정할 수 있습니다.

개발자들에게 계획을 세우기 위해 작업 시간을 추정하라고 요청했지만 실제로는이 접근법에 동의하지 않습니다 (사실 나는이 접근법에 강력하게 동의하지 않습니다). 예를 들어 4 시간이 걸리는 것은 실제로 의미합니다. 한 명의 개발자는 작업 자체에 시간 만 포함시킬 수도 있고, 다른 누군가는 차를 만들기 위해 시간을 추가 할 수도 있습니다!

예상 시간은보고 목적으로 항상 다른 사람에게 전달되며 전체 팀 노력에 비해 기능을 제공하는 개별 요소를 지나치게 강조합니다.

추정은 가장 큰 문제가 아닙니다

옆으로, 추정을 알아내는 것이 팀이 해결해야 할 가장 큰 문제는 아닙니다. 가장 중요한 것은 스프린트 전반에 걸쳐 작업을 수행하기 위해 팀으로 협력하여 마지막 날 테스트를 위해 모든 것을 넘겨주지 않는 것입니다. 2 주 스프린트 동안 꾸준한 기능의 흐름을보고 싶습니다. 위에서 설명한 팀 다이나믹은 이것의 큰 부분입니다. 스토리 포인트 추정은 계획을 세우는 데 도움이되며, 정기적으로 테스트에 제공 할 수있는 작은 스토리로 분류 할 필요가있는 큰 스토리를 볼 수 있습니다.

Wikipedia는 포커 계획을 잘 설명합니다 . 귀하의 사례에 중점을 두어 상태의 일부를 요약하겠습니다.

왜 포커를 계획합니까?

우선, "정상적인"추정치와 달리 계획 포커를하는 이유에 대해 모두 선상에 있어야합니다. 그 이유는 실제로 매우 간단합니다. 작업 시간 을 예상 할 때 우리 모두는 큰 시간을 보냅니다 . 거의 모든 연구에 따르면, 인간의 뇌는 단순히 시간이 많이 걸리는 작업을 추정 할 수 없다는 것이 밝혀졌습니다. (또한 추정치에서 2-3 일을 초과하는 티켓이 추정치에 비해 가치가없는 이유도 있습니다.)

노력이 아닌 왜 복잡합니까?

이것은 위와 함께 진행됩니다. 노력은 일반적으로 시간을 의미 하며, 우리는 그 점에 빠집니다. 대신 복잡도 는 객관적으로 정량화하기 어렵 기 때문에이 경우에 좋습니다. 이 이야기가 복잡해질 것이라는 것은 당신의 직감입니다. 다른 사람에게는 덜 복잡 할 수 있습니다. 그러나 실제로 얼마나 복잡한 지 정확히 정량화 할 필요는 없습니다. X시간이 걸리는 노력과 달리이 복잡한 작업 을 수행 할 필요는 없습니다. 결국에는 X며칠 이 걸리는 데 동의해야합니다 .

왜 카드를 숨기나요?

손님이 복잡했던 카드는 숨겨져 한 번에 공개됩니다. 이것은 자신의 초기 추정을하기 전에 다른 사람들의 의견에 영향을받지 않도록하기 위해 수행됩니다. 모든 사람이 복잡성 측면에서 같은 느낌을 가지고 있다면 끝났습니다. 매우 다른 숫자가 발생하면 거기에 숨겨져있는 무언가가 있다는 것을 알고 있습니다. 이러한 방식으로 모든 사람이 필요한 복잡성 / 노력에 대해 동일한 아이디어를 가지고있는 스토리를 매우 신속하게 처리 할 수 ​​있습니다.

왜 피보나치 숫자입니까?

카드의 숫자는 일반적으로 피보나치 숫자 또는 숫자에 많은 차이가있는 다른 종류의 시퀀스입니다. 이것은 당신이 직감을 느끼도록 강요하기위한 것입니다. 8과 13 사이에서 선택해야한다면, 그것은 9 나 10보다 훨씬 더 많은 진술입니다. 또한 위에서 언급 한 바와 같이, 큰 차이는 숨겨진 문제가있는 곳이므로 차이를 확대함으로써 이러한 문제를 더 잘 감지하십시오.

왜 이것이 작동합니까?

흥미롭게도, 계획 포커를 처음 몇 번 수행해도 작동하지 않습니다. 그렇게 간단합니다. "3"또는 "5"는 무엇을 의미합니까? 각 숫자의 의미 (의도적 의미)에 대한 정의는 없으며 각 숫자의 실제 의미를 발견하는 것은 전체 팀의 책임입니다. 이 숫자로 당신의 이야기를 추정 한 후에야 그리고 당신이이 중 몇 가지를 깨달은 후에 만 ​​5를 올릴 때와 8 일 때를 더 잘 이해할 수 있습니다.

이 개념을 속도 개념과 결합하고 이러한 스토리 포인트를 통해 스프린트 진행률을 측정하면 기존의 시간 추정과는 다소 독립적 인 완전히 새로운 차원의 효율성을 얻게됩니다.

그럼에도 불구하고 개인적으로 포커 계획의 가장 유리한 점은 시간 추정치 대신 피보나치 수를 사용하면 불확실성을 감지하기가 훨씬 쉽다는 것입니다. 고전적인 시간 추정을 사용하면 이러한 "극단적"(수의 차이로 인해) 결정을 내려야 할 필요가 없으므로 추정치가 다소 가깝고 팀이 이야기를 충분히 이해했다고 허위로 믿을 수 있습니다.

예

일반적으로 일어나는 일의 간단한 예는 이야기가 제시된 다음 사람 A가 이의를 제기하는 것입니다. "이 기능은 X에 영향을 미치므로 지금까지 생각한 것보다 비용이 많이 든다는 것을 잊지 마십시오." 주요 문제는 테이블에 항상이 사람 A가 있다는 것입니다. 누군가 염려하는 것이 항상 있습니다. 공개 토론이 있다면 X가 얼마나 큰 걱정인지 전혀 모른다.

시간을 기준으로 숨겨진 견적을 작성하면 조금 나아집니다. 그러나 여전히 이의가있는 사람 A는 아직 추정치에서 분명한 이상 치가 아닐 수도 있습니다. 반면 포커를 계획하면서 개인 A는 실제 문제 X의 정도에 대해 더 많이 생각해야합니다. 서로 다른 두 가지 문제의 경우 위의 "음성 이의 제기 텍스트"로 해당 중요성을 올바르게 구분할 수 없습니다. 시간 추정치가 있어도 어느 것이 더 문제가되는지 알기가 어렵습니다. 계획 포커를 사용하기를 희망하는 것은 하나의 이의가 다른 사람들의 추정치와 2-3 점이 다르지만 결국 중앙값에서 5 또는 8 점 떨어진 다른 이의가 가장 중요한 불확실성 일 수 있다는 것입니다 스프린트 계획의.

우리 팀에서 수십 번 반복 한 후에 이야기 포인트는 대부분 중기 프로젝트 조정에 관한 것임을 알았습니다. 이를 통해 제품 소유자는 2 ~ 3 개의 스프린트를 미리 계획하고 평균 속도를 기준으로 릴리스에 대한 비즈니스 및 범위 결정을 내릴 수 있습니다.

우리는 스토리 포인트가 스프린트 레벨에서 그다지 유용하지 않다는 것을 발견했습니다. 스프린트 2 개가 유사하지 않으며 얼마나 많은 작업이 수행 될지 예측할 수 없기 때문입니다. 결과적으로, 우리는 평가 부분에 집착하지 말고 포커 세션을 기능에 대한 대화를위한 구실로 계획하기로 결정했습니다.

이것은 Mike Cohn이 만든 점과 일치 합니다 .

참고로, 이것은 주어진 팀에 해당되지만 스토리 포인트가 어떻게 도움이되는지에 대한 규칙은 없습니다. 먼저 방법론을 고수하는 것이 좋지만 그것이 유용한 지 여부와 방법을 빨리 알아 내십시오. 회고는 그것을 반영하는 데 도움이 될 것입니다.

여기서 근본적인 문제는 그것이 깨 졌다는 것입니다. PM은 스프린트 (팀의 속도)에 몇 개의 스토리를 넣을 수 있는지 대략적으로 알기 위해 계획 포커를 사용하여 각 스토리의 복잡성을 파악하려고합니다.

결과적으로 "시간을 기준으로"인 "시간을 기반으로하지 않음"입니다. 모두가 혼란스러워하는 것은 놀라운 일이 아닙니다.

이 작업을 수행하는 방법이 있습니다. 먼저 노력을 잊고 복잡성에 집중하십시오. 각 스토리가 영향을 미치는 영역을 개발하고 집중하는 데 걸리는 시간을 잊어 버리십시오. DB, 서버 코드, 클라이언트 코드 및 클라이언트 문서를 업데이트하는 스토리가있는 경우 4 포인트 스토리라고 말할 수 있습니다. 그것이 DB sql에 대한 변경 일 경우 1 포인트 스토리입니다. 이를 통해 스토리 간의 상대적 복잡성을 파악할 수있는보다 이해하기 쉬운 방법을 제공합니다. (여러분의 상황에 맞는 몇 가지 측정 항목, 테스트 범위 요구 사항 또는 UI 복잡성 등)

제 의견은 일반적으로 미니 폭포 프로젝트처럼 스프린트 계획을 장려하는 무의미한 시간 낭비입니다. 스프린트에 몇 개의 스토리 포인트를 넣을 수 있을지 누가 ​​정말로 신경 쓰나요? 스프린트 마지막에 남은 스토리가있는 경우 다음 스토리에서 스토리를 수행하면됩니다. 이를 감안할 때, 당신은 백 로그를 당신이 가지고있는 모든 뛰어난 스토리의 크기로 만들고 시간이 지남에 따라 점차적으로 모든 내용을 정리할 수 있습니다. 배달 시간은 오래 걸리지 만 백 로그 및 스프린트 계획 회의에서 20 %의 시간을 낭비하지 않으면 더 빠릅니다. 프로젝트가 끝날 무렵, 얼마나 많은 스토리 포인트가 전달되었는지 신경 쓰지 않습니다. 사람들이 관심을 갖는 것은 전달 된 프로젝트입니다.

또한 사용자 스토리 포인팅은 재협상이 필요한지 비즈니스에 앞장서 게합니다. 한 달 안에 작업을 완료하면 100 점을 얻었을 때 어려움을 겪을 수 있습니다. 또한 서사적 인 이야기를 여전히 가치가 있으며 스프린트로 완료 할 수있는 작은 것으로 나눌 수 있습니다.