Estimation Difficulties

[Darren Weaver]

Currently we have a very involved process of completing estimates.

1.  We complete estimates using an "enhancement" ticket type and workflow

2.  The process is managed largely outside of JIRA with only entry of numbers occurring within JIRA.

3.  Numbers are entered in a custom field we created for estimation.

There has to be a better way.  Please help us!

[Nic Brough -Adaptavist-]

A very easy answer to this would be "Dump your external process and put realistic estimates into Jira".

I doubt that could work for you, there's probably a lot of stuff going on we don't know about which would get in the way of doing it better.  But we can't really tell you a lot more than that.

I would recommend getting a BA in to look at the process and how it could be improved (ideally, one with good Atlassian experience, so they can also help you translate it into Jira better)

[Darren Weaver]

does adaptavist have a recommended workflow for estimation.  Some of our clients request high level estimates and then refined estimates if the effort is within their cost benefit analysis.

[Nic Brough -Adaptavist-]

We couldn't make any recommendations without knowing a lot more about your processes and how you would really like to work.

High-level and refine later is a good starting outline, but there are so many options within it, we can't tell you a lot more. 

[Darren Weaver]

I'm just surprised that JIRA doesn't have estimates fields out of the box.

[Nic Brough -Adaptavist-]

It does!  Issues have an "original estimate" field, although the default project settings hide it from a couple of issue types in some cases.  The field is time based, not numbers though.

[Darren Weaver]

Our clients are provided a much more granular breakdown of estimation, e.g., QA time, dev design, development, requirements documentation, etc. across multiple components for each of our applications.  

That's the reason we had to create custom fields.  Would you recommend using the estimate issue type that, I believe, comes out of the box?

[Nic Brough -Adaptavist-]

That's a complexity Jira doesn't handle off-the-shelf.  I've dealt with it a couple of times though, with three totally different approaches (which can be combined)

• Scripts that take a set of numeric fields, add them up, and populate the original estimate field.
• Scripts that generate data for reporting.  These looked at either
  • the time logged by people and looked at what team they were in so it could allocate the time to a particular grouping of time
  • the time logged by people while the issue was in a particular status
• Sub-task the work, so that you have separate tasks (with their own estimates) for QA, dev design, dev, docs etc

[Darren Weaver]

What are the best practices that JIRA recommends for this type of scenario? My guess would be estimation subtasks but I'm not sure- there are multiple methods we could use but I hesitate to do much scripting due to scripts breaking with upgrades.

[Nic Brough -Adaptavist-]

It depends very much on what the data is for and what you are doing on it.

A good principle when trying to design or improve a Jira setup is to work backwards.  Essentially, you are putting data into something so you can track things and see progress.  The end result, no matter how you do it is "reporting".  What do your people want to see Jira telling them?

In your case, it sounds like they want sets of separate time estimates for different parts of a task.  I would lean towards the sub-task approach, because

• Sub-task estimates (original estimates, not Scrum/Kanban estimations) can sum-up on to their parent issues
• You can see at a glance an issue breakdown - look at the parent issue and then the subtask section, by default, you see the sub-estimates
• You can do really quick and obvious reporting by saying things like "issue-type = QA" or "issue-type = dev design"

You don't even need to make these sub-tasks complex - a workflow of "to-do" and "done" could be enough, with a summary and estimate field only.  A number of people I've worked with have had me write scripts that create and assign the subtasks automatically, so people can do estimates and tracking with minimal effort.