What is the best practice to manage multiple time estimations on an issue?

Question

We are using Jira Cloud and did not find the best practie for this issue.

we are looking for a solution that is commonly used when there is a need to have multiple time estimations on a single issue, for example I have a scrum team with Dev,QA, Devops etc.. each have a time estimation on an issue in the sprint.

What is the best method of managing this while providing visibility on each time estimation, best option i found so far is using sub tasks per each role in the team and estimate it?

Warren_mz9b4z · Answer

At a previous company we used the sub-task way which worked well. At my current company we've added 2 customfields, one for Dev Estimate and one for Test Estimate. We then manually add these 2 fields and put the total in the (Jira) Original Estimate field. A bit more hassle, but they can be displayed as columns in JQL results and are picked up via REST API queries

Daniel Ireland · Answer

Subtasks work, except when they don't. I know of a couple of views where the parent JIRA does not auto-calculate the sum of all the subtasks. But if they suit your use case, it's def the cheapest approach.

If you have the cash, Portfolio caters for multiple (defineable) workflow steps. You define your skills (eg UX, Dev, QA) and assign skills to your team, and then allocate an estimate per skill.

As a bonus, you then get an easy to scan view of all the sums for each skill across the project, and Portfolio tells you if you'll hit your deadline.

But, it isnt free.

Josh Steckler · Answer

Subtasks is how I would go since each issue is only allowed one assignee and one original estimate. Each team you have would have a separate subtask, and JIRA should be able to sum up the time estimates and worklogs for reporting and visibility on the parent.

I have gone so far in some cases as to write scripts that automatically create sub-tasks for groups on a specific workflow transition. Wrote the scripts myself rather than paying for a plugin.