Pros and Cons of estimating story points at a task level

[Garth Bond]

I have just joined an organisation that do all their estimations at a task level. I.e. there is no story point estimations, only at a task level. They say that had to do this because Jira could not show their management the actual work for work done to date or something like that.

What I would like to know from a Product prospective is how this effects the use of Jira overall as a result of this. They use Excel for Sprint Planning and it seems a waste given this is what Jira is designed to do.

Please provide me with your insights and recommendations for why this many not be a good idea and why?

[Trudy Claspill]

Hello @Garth Bond 

Welcome to the Atlassian community!

It is unclear to me what you mean by "at the task level" in the context of the company's Jira configuration.

The default issue type hierarchy for Jira is:

Epic (level 1)
|-- standard issues (level 0) i.e. Story, Task, Bug
    |-- subtask issues (level -1)

For Sprint Velocity and burdown/up native reports the information is based on estimations used at Level 0 - Standard Issues.

What level is the company's "task" at? Is it not at Level 0?

[Garth Bond]

No they don't estimate the story points for a requirement. What they do is take the Story point and break it down into sub-tasks which are assigned to the development team. They estimate the sub-tasks not the story as a whole. I think this is the reason none of the Jira standard reports work. 

I cannot pin-point exactly why they do this. The only thing I can gathers is that they need full visibility in everything that has been done, not just when a story is completed for some reason.

Does this seem odd to you?

Regards

Garth

[Trudy Claspill]

The primary argument against this when using Jira is that the native burndown/up reports won't support it and can't be forced to support it. That would require a third party app that would add to the overall cost of the system. And the methodology they are using has prompted them to use a different tool for sprint planning rather than using the native capabilities.

It would require a better understanding of what their reporting and sprint planning needs are, and how they currently are doing their estimation, to formulate suggestion on how they might achieve the same using the Jira functionality as it is designed to be used.