Portfolio for Jira Cloud Unestimated Items not populating from default

[Jason Baab]

We are using Portfolio for Jira (cloud) and are experiencing an issues regarding unestimated items. He wave new boards in new projects and have many issues from Jira that are not yet estimated. When we use Portfolio, only those issues with story point estimates are showing on the roadmap (unless using "Target Schedule"). I have the parameter for Unestimated Item Scheduling set to Base on Default Estimates. I have the following values set: Story - 3, Epic - 8, Initiative - 40. However, I cannot get the default story points to apply to unestimated items.

[Earl McCutcheon · Accepted solution]

Hello Jason,

If the 'Unestimated item scheduling' set to 'Base on default estimates', the values should show up greyed out in the scope.

A bit of clarification though, are the values just not showing up at all, or are you showing values, that are not what you are expecting i.e. the 8 and 40 for the epic and initiative level, as if there is a value present in a child issue the value is summed up to the parent.  So if you had a initiative with a child epic that contained a single story, the roll up would be 3 at the initiative hierarchy level.

Next double check if it's the system 'Story Points' field being used and not the 'Story point estimate' for next gen projects or possibly a secondary custom field called 'story points'.  This will show up in the scope view settings menu and the system default 'Story Points' field should be the second from the top just under releases like this:

And if you had additional custom fields added they would be lower on the list like this:

Regards,
Earl

[Jason Baab]

Thanks for the response Earl!

To clarify, any issue that is not story pointed in Jira shows as "0" in Portfolio. I checked the field showing in Scope is "Story Point" as you have shown. 

Any issue that is story pointed in Jira does carry over and rolls up from child to parent.

Thanks for your input!

[Earl McCutcheon]

Hi Jason,

Thanks for that additional info, and it sounds like what is occuring is that the field has a value present of "0" and is not null (empty), so effectively the value of "0" is taking priority over the default values that only populate if the field is left blank.

if you select the field and clear the 0 with a delete or backspace, does the default value populate?

Regards,
Earl

[Jason Baab]

Earl,

You are right - when I click in the Story point of a Story and delete the value, hit ENTER and the Story Point changes to the default (3).

Is there a way to "bulk" change these in Portfolio or must I do then all individually?

Thank you so much for your help!

[Earl McCutcheon]

Hi Jason, 

There is not a bulk option in Portfolio directly, but you can do bulk modifications from the issue navigator covered in detail in this Document:

• Editing multiple issues at the same time

I would recommend using a JQL filter like "story points = 0" and bulk edit the issues to clear the field, adding in any additional restrictions you need in place for items where you do not want to modify the field.  For referance you can also see the differentiation in 0 vs NULL in the jql using the following opposing queries:

• For a value of Zero:
  • story points = 0
• For a NULL value:
  • story points is empty

Once you have the issues identified, Trigger a Bulk "Edit" select the check box next to the story points field and leave the field blank.  This will modify all the issues to remove the "0" value from the field.

Next, some additional information just for a bit of caution on using zero's.  Realistically a story point should not be expressly set to zero as agile methodologies go.  For the matter of a zero-point estimate methodology this simply indicates that delivering that item does not require any measurable effort so it should be ignored and completed without effort.

However, this is not realistic and will over time cause errors in estimation, as any effort for good measure is going to have some weight, and a good way to think of it is the logic trap where a single event is not easily measurable but if you attempted completing an infinite number of near zero tasks it would take infinite time to achieve.  There are scenarios where you might want a zero expressly set such as a soon to be canceled work item that is being left behind as a historical referance point while finalizing planning and the allocation of a unit of measure is not realistic for a one off unit like this, but these items should always be outliers and never the norm.  Preferred method is leave the value empty when no effort value is ready to assign, then assign a weight when ready to plan to get an accurate measure your velocity.

Also as computer logic and Jira comprehension of that logic is concerned for math equations code prefers a NULL value  over an integer Value that is representing Null in almost all scenarios, as technically 0 is a value although it represents the absence of one mathematically but the code is going to consider it a manual overwrite to preserve the value placed in the field, and force the out of scope behavior in scenarios where you actually want a zero or undefined.

Regards,
Earl

[Jason Baab]

Earl - YOU ARE THE MAN!

Not sure why all of our unestimated issues in Jira defaulted to Story Point of "0" instead of "null". I did a bulk edit using the JQL you suggested and now Portfolio is using the default estimates set in the configuration. 

Thanks again for all of your help and input!