Question about JIRA version report's predicted release date

[Christophe]

I have a question about JIRA's version report: 

According to the documentation, the predicted release date is based on the "estimated work remaining". When certain tickets have no estimation, does that mean that the prediction assumes there is no work associated with these tickets?

For example in our company not all stories are estimated right away and defects are (by design) never estimated. In order to estimate stories, we use story points.

[Guy LaRochelle]

And as for the items that you're never planning on estimating, you can set them to 0 instead of leaving them empty.

[Walter Buggenhout]

Hi Christoph,

The prediction does not assume there is no work associated with the unestimated issues, but as there is no estimate, it cannot take them into account for the prediction.

There is some information that might help you interpret the accuracy of the report:

A first thing - as also mentioned in the documentation your refer to - is the optimistic and pessimistic predicted release date. The prediction adds 10% of uncertainty / deviation to your velocity metric of past work delivered to account for fluctuations in the speed of delivery.

And second, there is an indication of the percentage of unestimated issues in your backlog (shown in red in the chart). Although they aren't quantified, it gives you an indication of the work in your backlog that is not accounted for in terms of estimations. So you at least get a feel of how reliable the predicted release date might be at a given point in time.

[Christopher Krause]

@Walter Buggenhout what would be nice is if the same chart was provided but considered cycle time and used monte carlo instead of estimates - that would be REALLY powerful.

Why use a 10% for pessimistic and optimistic when you can use a monte carlo simulation? The chart would look the same, it would just have a confidence band with multiple "times to complete" with a % of certainty. 

[Alasdair Duncan]

@Walter Buggenhout It would make sense for the Un-estimated Issues to be given an assumed size (for charts and Sprint sizing) until actively sized.

This is essentially what happens now, just that the assumed ticket size is 0.

There just needs to be a question asked when a Project is opened:

"What size should be given to un-estimated issues (until they are estimated)?"
Options: 1,2,3,5,8,13... OR "Mean/Median/Mode of sized Issues"

[Guy LaRochelle]

Also, if a story is linked to an epic that has been estimated, one could question if that story should be included in the "unestimated" work...

For example:

Epic A: 20 points

   Story A.1: no points

   Story A.2: no points

Well, until the stories get estimated themselves and then we remove the 20 points from the epic, they are still roughly estimated through the epic, no?