Each x% has a different definition - but the most important things to check first:
1) Make sure you click Calculate in the top right. If you associated Themes in the Scope view but didn't click calculate, these won't update the percentages on the Themes tab.
2) As with all percentages, make sure you have a numerator and denominator for the Theme. Which is to say, make sure you have a theme applied to at least one ticket with an estimate on it. Sounds like you do.
1) Target of course is not calculated, it's manually entered.
2) Estimate: "Sums up all backlog items labeled by theme and calculates the percentage relative to all backlog item estimates." This one is tricky, since the UI reflects Theme assignment a little different than actual. You can apply a Theme to a standard issue level item (Story, Task, Bug) and it will include the estimate for that item. OR, you can apply a Theme to something further up the hierarchy (Epic, Initiative, etc) and it will include the estimate for that ONLY if you explicitly apply the theme at that level. But, if you have estimates only at the child items, it will only take the themes from the child items. AND if you have multiple themes on these child items, it will virtually (but not really) apply the theme to that parent item in the UI, but the numbers come from the child items. Typically early on estimates are applied at parent levels, then as the stories are filled out and estimated under, you'd back out the hard estimate at the parent item to better reflect the actual work.
Which bring up the question: let's say you apply Theme A to an Epic then put an estimate on it. Then you come back in a month and start adding stories under that Epic with values, but some are Theme A and some are Theme B - how does it know what to add to the Estimate for that Theme?
I grabbed one of the Portfolio SMEs at Summit 2019 and we agree that if you LEAVE that estimate on the Epic, and you had set a Theme for it, it will carry that forward, even if you later put different Themed stories under it and see two themes virtually in the UI. You can avoid this by making sure when you add that first story under an Epic, make sure to remove the set estimate on the Epic. I'm still not 100% convinced on this, but it should get you close.
3) Actual says it's about "work logs" in the documentation, but actually it's completed values for whatever estimation statistic you use that's reached a Done category status (green). NOT what your done status is on the agile board consumed, which can be a yellow status.
Themes are essentially going away in Portfolio 3.0 - they replaced them with color coded labels and later keyed to certain custom fields so you have more flexibility on which data point you report/pivot on.
Thanks for taking the time to explain. I was able to figure out how Actuals work very quickly with smaller set of data and it makes sense. Your response confirms my understanding.
But for Estimate chart, I am not sure if it is going to add much value in a true agile world. Below are few reasons.
- We have 100's of items in the backlog and I usually don't recommend estimating all the work upfront, especially if you are not going to work on those epics and stories in a while. Priorities shift constantly and its a waste of teams time estimating work that they are not going to work on in near future (even if it takes 30min/per epic its a lot when you have more than 10 epics). So in our portfolio backlog we have some work that is not estimated.
-Team is using Original Story Points Estimate field to capture their baseline estimate (not Story Point field at parent level). We decided to do this so team doesn't have to keep updating the total estimate at parent level after the child stories are created. This is another overhead I see and I wish jira team can figure out how to remove this overhead.
Because of above 2 reasons, I don't think we will get much value out of Estimate pie chart.
