Configuring estimation so the charts mean something

Estimation answers how big the work is. Tracking answers how much of it is left. Jira treats those as separate settings, and Atlassian's configuration page says so directly: you set how work items are estimated, and separately how progress is tracked, noting that it is common for teams to estimate with one method and track with another.

That separation is the source of the most common confusion in this whole area. A team estimates in story points, someone enables time tracking so people can log hours against a client, and now the sprint report is being driven by remaining estimate rather than points. Nothing broke. Two different settings are simply doing what they were told.

The same page describes the mechanism precisely: selecting None for tracking uses whatever you defined as the estimation method, while selecting remaining estimate and time spent tracks progress by subtracting time spent from the original estimate. Pick one on purpose. Do not let the second setting be a side effect of somebody wanting a timesheet.

This is the part that wastes an afternoon. There are two screens, they are in different places, and the documentation for one does not apply to the other.

In a company-managed project, estimation is a board setting, reached through board settings, and Atlassian notes it can only be changed for company-managed Scrum teams. You need to be a project administrator for the board's location or a board administrator.

In a team-managed project, estimation is a project feature that is off by default. You turn it on in the project's features and then choose story points or time. Atlassian warns that enabling it causes several changes you should understand first, which is a polite way of saying do not do this in week three of a live sprint.

If you have not settled which project type you are on, that decision comes first and is worked through in team-managed or company-managed. Configuring estimation before that choice is settled means configuring it twice.

Atlassian's velocity documentation lists exactly these four options for the estimation statistic: story points, original time, work item count, or any numeric custom field in the system. That list is worth knowing because most teams assume the choice is points or hours and never see the other two.

Item count deserves more consideration than it gets in agency work. If your team already slices work to roughly a day, counting items is as accurate as pointing it and costs zero estimation meetings. If your team does not slice consistently, item count is the worst option on the list, and you will not find out for two months. The wider argument between relative and absolute sizing is in story points or hour bands.

This is the single most consequential detail on this page, and it is stated in a single line in two separate Atlassian documents.

The velocity chart page says estimates from subtasks are not included in the calculation, and only estimates from parent items are counted. The burndown page says the same thing about story points on subtasks: only story points on parent items are included.

Now consider the common agency pattern. A parent item is created as a container and left unestimated, and the real work is estimated on five subtasks underneath it. Every one of those estimates is invisible to the velocity chart. The team completes a full sprint of work and the chart shows a fraction of it, which then feeds a forecast that is wrong in the same direction every time.

Atlassian documents the estimate itself as a value set on the work item, with no aggregation promised, so the fix is a convention rather than a setting: estimate at the level the chart reads, which is the parent. Use subtasks for splitting the work between people, not for sizing it. If your team genuinely needs subtask-level estimates, accept that velocity is no longer your forecasting instrument and use throughput instead.

Two more inheritances catch people, and both are documented on the same chart pages.

The first is the board filter. Both the burndown and the velocity charts are board-specific and only include work items matching the board's saved filter. So a work item that is genuinely part of the sprint but excluded by the filter is not in the chart, and the chart will not tell you.

The second is column mapping. An item counts as done when its status maps to the right-most column, which means completion in every chart is defined by a board layout decision rather than by your workflow. That connection is the reason workflow design people will actually follow treats the right-most column as a contractual boundary.

One more from the velocity page, and it changes how you read the grey bar: the commitment total is the estimate of everything in the sprint when it starts, and items added after the sprint begins, or estimates changed after it begins, are not included in that total. Completed work does include the scope changes. So a sprint that took on extra work mid-flight shows a completed bar higher than its commitment bar, and that is not a data error, it is scope change rendered honestly.

Sometimes you have to. The team was pointing, the client now wants hours, or the reverse. The change itself takes a minute. The consequence lasts as long as anybody looks at historical charts.

Do the arithmetic before you decide. Say six sprints of history at an average of 24 points completed. Switch to hours, and the next chart shows an average of 130. Nobody reading that chart in six months will know the axis changed, and the obvious reading is that the team suddenly got five times faster.

So do three things. Make the change at a sprint boundary, never mid-sprint. Record the date and the reason somewhere the chart's readers will find, which usually means a note on the project's Confluence page rather than in the Jira configuration history. And do not backfill estimates in the old unit onto historical items to make the chart continuous, because that produces a smooth line that is fiction.

For an engagement that is more than a few months old, the better answer is usually to leave the existing project alone and change the method at the start of the next phase, where the discontinuity lines up with something a reader already knows about. That is the same instinct behind recording a baseline before a programme starts: the only reason 159 tracked work items told the sponsor anything was that they were counted the same way from the first phase to the last.

One boundary worth holding. Configuring estimation in Jira decides how the team tracks work internally. It does not answer what the client is charged, and the two should not be the same number on the same screen.

Estimation settings drive sprint charts, which are an operational instrument for the team. Commercial estimates are a negotiated number with contingency in it, and they belong in the scoping document, not in a field a developer can edit. Keeping those separate is the reason a statement of work scoping exercise is a different activity from sprint planning, even when the same person runs both.

The failure when they get merged is specific and expensive. The client sees a chart showing 40 points completed, asks what a point costs, and now every future estimate is an implicit price quote. Once that has happened, the team's estimates stop being estimates and start being negotiations, and the charts stop being useful for the only thing they were ever good for.