nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Time Tracking in Jira

Krisna Leo Parista

Hello,

I am a newbie as a Scrum Master.

I set story point to track velocity of the team. However, the new Product Manager wants to know how much time exactly does each team member spent on a task (for observation).

I am trying to accommodate this issue without affecting the story points. If the team member fill in the time tracking, will this be a problem by the end of the sprint (with the velocity chart or sprint report). Or maybe does anybody have a better solution? Time Tracking.jpg

Cheers,
Krisna

Accepted answers

Nic Brough -Adaptavist-

Actually, no, no problems at all. Atlassian recommend doing what you suggest if you want to plan and do Scrum with one metric and record and track time as well.

The Velocity chart has a parameter of "estimation statistic" and it uses just that one single field for the velocity. That is usually set to "Story points", but many of us use other statistics (Business Value for example), and some do actually want to do it on time units (hours or minutes) so they use time-tracking. It's not strictly Scrum or particularly Agile, but it's not a bad thing to do (and it's better than no estimation/velocity)

But the chart only looks at one number field. In your case, carry on using Story Points, ask your people to log time, and ask your managers to look at the time reports as well as velocity. The time tracking will not affect your velocity charts.

All comments

Nic Brough -Adaptavist-

Actually, no, no problems at all. Atlassian recommend doing what you suggest if you want to plan and do Scrum with one metric and record and track time as well.

Krisna Leo Parista

Hi Nic,

Thank you for your response. Glad to hear that it won't affect anything, I will ask the team to insert the time tracking for this sprint.

Then, I have a look at the time tracking report:
original estimate.jpg

For the next sprint, does it mean that the team have to insert the original estimate in order to have a full report on the time tracking?

Thank you Nic.

Cheers,
Krisna

Nic Brough -Adaptavist-

You do not need to enter time estimates - remember your velocity and burn are all coming from Story Points, not the time tracking. There's no harm in entering time either.

One of our clients even has a standard where when a team member picks up the next issue to deal with in the sprint, they're asked for a time estimate then (well after the start of the sprint). It's optional, but most do it, as it stops other people asking "how much longer will it take?" as they can see the estimate/logged and hence progress without having to ask. But you don't have to!

Emre Toptancı [OBSS]

Hello @Krisna Leo Parista

If your developers are updating their Jira issues on time (for example if they move the issue to InProgress as soon as they start working, move to resolved as soon as it's done, and always assign the issue to the relevant person immediately) you can use the status and assignee times of issues to get an idea about time spent on issues.

Our team at OBSS built Time in Status app for this need. It is available for Jira Server, Cloud, and Data Center.

Time in Status allows you to see how much time each issue spent on each status or assigned to each assignee. You can also combine statuses into consolidated columns to see metrics like Ticket Age, Cycle Time, or Lead Time.

You can calculate averages and sums of those durations grouped by issue fields you select.

tisCloud_StatusDuration_LeadTime_with Estimates.png

The app calculates its reports using already existing Jira issue histories so when you install the app, you don't need to add anything to your issue workflows and you can get reports on your past issues as well.

Time in Status reports can be accessed through its own reporting page, dashboard gadgets, and issue view screen tabs. All these options can provide both calculated data tables and charts.

Using Time in Status you can:

See how much time each issue spent on each status, assignee, user group and also see dates of status transitions.
Calculate averages and sums of those durations grouped by issue fields you select. (For example, see average InProgress time per project and per issue type.)
Export your data as XLS, XLSX, or CSV.
Access data via REST API. (for integrations)
Visualize data with various chart types.
See Time in Status reports on Jira Dashboard gadgets

https://marketplace.atlassian.com/1211756

EmreT

Krisna Leo Parista

Hi Nic,

Well noted! Thank you for solving this problem. )

Cheers,
Krisna

Mehmet A _Bloompeak_

Hi @Krisna Leo Parista ,

As an alternative, you can try Status Time app developed by our team. It provides reports on how much time passed in each status or assignee. This way you can automatically know how much time a developer worked on a story.

Once you enter your working calendar into the app, it takes your working schedule into account too. That is, "In Progress" time of an issue opened on Friday at 5 PM and closed on Monday at 9 AM, will be a few hours rather than 3 days. It has various other reports like assignee time, status entry dates, average/sum reports by any field(eg. average in progress time by project, average cycle time by issue creation month). And all these are available as gadgets on the dashboard too.

If you are looking for a free solution, you can try the limited version Status Time Free. Hope it helps.

Yuliia_Borivets__SaaSJet_

Hi @Krisna Leo Parista

There is no harm in combining story points and time tracking. My team uses story points to evaluate the amount of work that a team can accomplish in a sprint and monitor time spent as well. When evaluating a team's work, it's useful to compare:

how many SPs each employee closed based on their original estimates
how much time the task took in the progress

Here's an example of how to acquire these results using a pivot table.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-core

atl-gruland