Cloud
Data Center 10.2
Versions

Estimate in story points

Learn to plan and estimate for scrum teams

On this page

Related content

  • No related content found

Still need help?

The Atlassian Community is here for you.

Ask the community

  1. Plan for the team
  2. Customize the team board
  3. Estimate in story points
  4. Analyze team reports
  5. Optimize future plans

There's a huge variety of ways to estimate stories, but the objective of every approach is to be able to get better at predicting how much work the team can do each sprint. In agile scrum, this translates to knowing the team's velocity.

Velocity measures the number of 'estimation units' that a team usually completes from sprint to sprint. It is effectively a productivity rate based on an estimation of volume of work, and it is best worked out in a measure other than 'time'.

What are story points?

Story points are a commonly used measure for estimating the size of an issue in scrum teams. During a typical planning session, a trivial bug fix might be estimated as a 1 or 2, and a larger feature might be anything up to a 12. Note that the scale of points does vary between scrum teams. Some use 1-12, others 1-5. The key is to use the same scale so that your velocity is consistently calculated.

If issues are estimated larger than this, they might need to broken into smaller stories or subtasks.

The focus is on story points here because it's the more common scrum estimation method, and we use it at Atlassian. Your company may use hours or ideal days. If you do use time for estimation, you might want to have a look at Configuring estimation and tracking.

"Even seasoned devs can't estimate accurately in hours/days. We just need to predict what can realistically get done with a reasonable degree of certainty. Story points all the way."

~ Atlassian Developer

Q: Why use story points instead of hours?

A: It is much more useful in the long term to roughly predict how much work your team can do each sprint, than it is to try to estimate how long each story will take in time.

Story points enable the team to estimate stories in comparison to other stories, instead of forcing them to determine the time it will take to complete each story. Velocity is then worked out based on how many points the team can complete in each sprint. After a few sprints, team velocity stabilizes and estimation accuracy increases (or rather the same degree of inaccuracy is applied).

The problem with using hours to estimate is that the team is likely to estimate using the 'working hours' of the sprint (with some buffer time) and this is almost never an accurate reflection of a story's complexity or size. Accurate velocity is difficult to establish when stories are estimated in isolation, instead of by comparison.

Estimation, time and velocity are really critical things to understand. Read more in the Estimating an issue topic.

Estimate in points, track in time

Even when you estimate in story points, you can still track in time if you want. Knowing the team velocity (regardless of the measure used) enables you to roughly guess how long estimated backlog items will take to complete. 

But Jira Software does also have a couple of dedicated fields (Remaining Estimate and Time Spent) to track time while using story points.

(warning) NOTE: You need to be a board admin to make any configuration changes to a board. If you created the board, then you're already the admin.

Go to Board > Configure > Estimation.

Estimation section. Estimation Statistic is set to Story Points, and Time Tracking to None.

  • Select the Estimation Statistic (unit of estimation) - choose from story points, original time estimate, and issue count.
  • Switch on the Remaining Estimate and Time Spent option to get a more accurate picture of how things are tracking in time units.
  • If you leave Time Tracking as None, you can still refer to reports such as the Burndown chart to monitor progress.

 Find out more about how time tracking work in projects in the configuring estimation and tracking topic.

Fun fact: Inaccuracy is good

The goal of velocity is to be able to look at a backlog of not particularly well-understood stories, and guess how many sprints it will take to complete. It requires a similar level of uncertainty for all of the estimates in the backlog. Determining accurate velocity relies on the equality of the inaccuracy, which is why you should NEVER re-estimate issues after a sprint has started.

tip/resting Created with Sketch.

LEARNING ACTIVITY

In your dummy project, go to Board > Configure > Estimate page and change the Estimation statistic to one of the following:

    • Story points
    • Original time
    • Issue count

Note the differences when you create and estimate an issue.

Previous

Next

Last modified on Jun 23, 2020

Was this helpful?

Yes
No
Provide feedback about this article

Related content

  • No related content found
Powered by Confluence and Scroll Viewport.