Estimation setting

Estimation is available in Scrum boards only. As part of planning for sprints, issues can be estimated when in the Backlog to get an idea of how much work (or effort) an issue will take and therefore, how much total work is being committed to in a sprint. Estimation is an activity central to scrum development and helps to inform the team’s velocity.

There are two options to configure in a scrum board. Estimation Statistic represents how your velocity will be measured from sprint to sprint against these estimates. You can choose:

Story Points: the most commonly used option.
Original Time Estimate field: By default, this is specified in minutes, but you can use hours, days, or weeks, depending on your Jira system configuration.
Issue Count: which means estimation is based on the number of issues in the sprint.
The 'Estimate' field will not be editable in this case.
And finally, you can base estimation on any numeric custom field in your Jira system.

Estimates are entered on issues in the backlog in the Issue Detail View.

There is also a configuration option for the Time Tracking statistic. You can choose

None: in which case issues will burn down their Estimation Statistic value upon completion (usually Story Points). Or you can use
Remaining Estimate and Time Spent: in which case you will track time against issues using Jira's Remaining Estimate and Time Spent fields.

By default, these fields are specified in minutes, but you can use hours, days, or weeks, depending on the unit of time selected in Jira system configuration.

Note that this is fundamentally different from using the Estimation Statistic for burndown, in that values do not burn down when an issue is completed — instead, values only burn down when users enter Time Spent or set the Remaining Estimate to a new value.

추정 기능은 스크럼 보드에서만 사용할 수 있습니다. 스프린트 계획의 일환으로 백로그에서 이슈를 추정하여 이슈에 얼마나 많은 작업(또는 노력)이 필요한지, 따라서 스프린트에서 투입되는 총 작업량이 얼마인지 파악할 수 있습니다. 추정은 스크럼 개발의 핵심 활동이며 팀의 속도를 파악하는 데 도움이 됩니다.

스크럼 보드에서 구성할 수 있는 옵션은 두 가지입니다. 추정 통계는 스프린트에서 스프린트까지 속도를 이러한 추정치와 비교하여 측정하는 방법을 나타냅니다. 선택할 수 있습니다:

스토리 포인트: 가장 일반적으로 사용되는 옵션입니다.
원래 시간 예상 필드: 기본적으로 분 단위로 지정되지만 Jira 시스템 구성에 따라 시간, 일 또는 주 단위로 사용할 수 있습니다.
이슈 수: 스프린트의 이슈 수를 기준으로 예상 시간을 지정합니다.
이 경우 '예상' 필드는 편집할 수 없습니다.
마지막으로, Jira 시스템의 모든 숫자 사용자 지정 필드를 기반으로 추정할 수 있습니다.

예상은 이슈 세부 정보 보기의 백로그에 있는 이슈에 입력됩니다.

시간 추적 통계에 대한 구성 옵션도 있습니다. 다음을 선택할 수 있습니다.

없음: 이 경우 이슈가 완료되면 예상 통계 값이 소진됩니다(일반적으로 스토리 포인트). 또는 다음을 사용할 수 있습니다.
남은 예상 및 소요 시간: 이 경우 Jira의 남은 예상 및 소요 시간 필드를 사용하여 이슈에 대한 시간을 추적합니다.

기본적으로 이러한 필드는 분 단위로 지정되지만 Jira 시스템 구성에서 선택한 시간 단위에 따라 시간, 일 또는 주를 사용할 수 있습니다.

이슈가 완료될 때 값이 소진되는 것이 아니라 사용자가 소요 시간을 입력하거나 남은 예상치를 새 값으로 설정할 때만 값이 소진된다는 점에서 이는 번다운에 예상 통계를 사용하는 것과 근본적으로 다릅니다.

The goal of estimation is for the team to achieve reliable velocity. Velocity is the number of estimation units (basically, the amount of work) that a team can complete within a sprint. Any metric type will work to determine a team’s velocity, but Story Points are most common. And we will explore why in just a moment.
In order for velocity to be reliable – and to be reflected accurately in reports – issues should be estimated when in the Backlog before the sprint is started. This becomes the sprint commitment.
The team should also complete their sprints on time because reports (especially Velocity charts) rely on completing sprints within the same time-boxed duration (commonly 2 weeks).
The team should avoid scope changes (either adding issues to an active sprint or removing them). Scope changes have an impact on your report quality.
Finally, all statuses should be mapped to columns otherwise unmapped statuses will not be shown in reports.

Estimation improves over time.

추정 작업의 목표는 팀이 신뢰할 수 있는 속도를 달성하는 것입니다. 속도는 팀이 스프린트 내에 완료할 수 있는 추정 단위(기본적으로 작업량)의 수입니다. 모든 메트릭 유형이 팀의 속도를 결정하는 데 사용할 수 있지만, 스토리 포인트가 가장 일반적입니다. 잠시 후에 그 이유를 살펴보겠습니다.
속도를 신뢰할 수 있고 보고서에 정확하게 반영하려면 스프린트를 시작하기 전에 백로그에서 이슈를 예상해야 합니다. 이것이 스프린트 커밋이 됩니다.
또한 보고서(특히 속도 차트)는 동일한 시간 상자 기간(일반적으로 2주) 내에 스프린트를 완료하는 데 의존하므로 팀은 제시간에 스프린트를 완료해야 합니다.
팀은 범위 변경(활성 스프린트에 이슈를 추가하거나 제거)을 피해야 합니다. 범위 변경은 보고서 품질에 영향을 미칩니다.
마지막으로, 모든 상태는 열에 매핑되어야 하며, 그렇지 않으면 매핑되지 않은 상태는 보고서에 표시되지 않습니다.

추정은 시간이 지남에 따라 개선됩니다.

Especially when it involves everyone on the team (developers, designers, testers, deployers). Each team member brings a different perspective on the product and the work required to deliver a user story. Oftentimes, teams use different techniques such as planning poker to do estimation.

특히 팀원(개발자, 디자이너, 테스터, 배포자)이 모두 참여하는 경우 더욱 그렇습니다. 각 팀원은 제품 및 사용자 스토리를 전달하는 데 필요한 작업에 대해 서로 다른 관점을 가지고 있습니다. 종종 팀은 플래닝 포커와 같은 다양한 기법을 사용하여 추정을 수행합니다.

As we mentioned before:

Story Points are the most common estimation statistic.
• Story points are a relative measure of the amount of work required to complete an issue. They are provided in a Fibonacci-like format: 0, 1, 1, 2, 3, 5, 8, 13, 21…. For example, an issue that is assigned two story points is assumed to involve about twice as much effort as an issue that is assigned one story point.
Story points are used to help the team decide how many issues can be completed in a sprint. Each team will estimate work on a slightly different scale, which means their velocity will naturally be different. This, in turn, makes it impossible to play politics using velocity as a weapon.

앞서 언급했듯이

스토리 포인트는 가장 일반적인 추정 통계입니다.
스토리 포인트는 이슈를 완료하는 데 필요한 작업량을 상대적으로 측정한 것입니다. 피보나치와 유사한 형식으로 제공됩니다: 0, 1, 1, 2, 3, 5, 8, 13, 21.... 예를 들어 스토리 포인트가 두 개 할당된 이슈는 스토리 포인트가 한 개 할당된 이슈보다 약 두 배의 노력이 필요한 것으로 가정합니다.
스토리 포인트는 팀이 스프린트에서 완료할 수 있는 이슈의 수를 결정하는 데 사용됩니다. 팀마다 조금씩 다른 규모로 작업을 추정하므로 당연히 속도도 달라집니다. 따라서 속도를 무기로 정치를 하는 것은 불가능합니다.

Using Story Points, versus hours, reduces anxiety around accuracy. Sprint estimation becomes more and more reliable with practice. You can use actual hours, but it's not reasonable to assume that all hours of a week are productive. Dates don’t account for the non-project related work that inevitably creeps into our days: emails, meetings, and interviews that a team member may be involved in. Dates have an emotional attachment to them. Relative estimation removes the emotional attachment. Developers have a general sense of how much they can accomplish during a 2-week sprint - allowing for over or under estimating.
By default, the Story Points field is only available to issues of type 'Story' or 'Epic' (not 'Bugs' etc). But this can be changed by associating the Story Points field with other issue types and then specifying the screens that the Story Points field should be
displayed on.
Don't assign time values to story points. Doing this obviates the main reason to use story points in the first place.

시간 대신 스토리 포인트를 사용하면 정확도에 대한 불안감을 줄일 수 있습니다. 스프린트 추정은 연습을 거듭할수록 점점 더 신뢰할 수 있게 됩니다. 실제 시간을 사용할 수는 있지만 일주일의 모든 시간이 생산적이라고 가정하는 것은 합리적이지 않습니다. 날짜는 팀원이 관여할 수 있는 이메일, 회의, 인터뷰 등 프로젝트와 관련이 없는 업무는 고려하지 않습니다. 날짜에는 감정적인 애착이 있습니다. 상대적 추정은 이러한 감정적 애착을 제거합니다. 개발자는 2주 스프린트 동안 얼마나 많은 것을 달성할 수 있는지에 대한 일반적인 감각을 가지고 있으므로 과대 또는 과소 추정이 가능합니다.
기본적으로 스토리 포인트 필드는 '스토리' 또는 '에픽' 유형 이슈('버그' 등 제외)에만 사용할 수 있습니다. 하지만 스토리 점수 필드를 다른 이슈 유형과 연결한 다음 스토리 점수 필드가 표시되어야 하는 화면을 지정하여 변경할 수 있습니다.
스토리 포인트에 시간 값을 할당하지 마세요. 이렇게 하면 애초에 스토리 포인트를 사용하는 주된 이유가 사라집니다.

This example demonstrates the various things we have just covered.

First of all, this is an Active Sprint as we can see.
Story TIS-30 has an estimate of 2 Story Points
Story TIS-12 is unestimated, which means that estimating it during the sprint will be considered Scope Change and will register on reports.
And TIS-8 is a Bug and (by default) the Story Points field is not available on Bugs, so there is no estimation lozenge at all on this card.

이 예는 방금 다룬 다양한 내용을 보여줍니다.

우선, 보시다시피 이것은 활성 스프린트입니다.
스토리 TIS-30의 예상 스토리 포인트는 2개입니다.
스토리 TIS-12는 추정되지 않았으므로 스프린트 중에 추정하면 범위 변경으로 간주되어 보고서에 등록됩니다.
그리고 TIS-8은 버그이며 (기본적으로) 버그에서는 스토리 포인트 필드를 사용할 수 없으므로 이 카드에는 추정 사탕이 전혀 없습니다.