Historical inconsistencies

[James Overell]

When looking at graphs, we had around 1000 points get transferred from one team to another

They no longer exist in the SM project so now they they do not appear to be reflected historically, so there is no dip in the backlog.

However as they have been introduced in TL project there is a spike up here.

Is there any way to reflect the reduction in the SM project?

‌

‌

[Danut M [StonikByte]]

Hi James,

‌

Thanks for posting.

1. How did you move the points? By moving the issues from a project to another?
2. By changing (removing) the estimate of the issue in SM and adding the estimated to the corresponding issues from TL?

If you moved the issues (option 1), so they are no longer returned by the filter of SM), then the SM gadget will not show a dip, because not being the gadget’s filter the gadget no longer considers these issues. But the total scope and the actual numbers in the gadget should reflect the current totals (after moving the points). This is by design.

Using option 2 above would end-up in showing the dip in SM and spike in TL. But it is probably not so convenient to duplicate issues.

‌

Thank you,

Danut Manda

[James Overell]

Thanks, I understand how it works.

It’s not going to work for us as we need to have static baselined measurements which can’t be done with this.

Thanks anyway.