rejected items should reduce the current scope

[Daniel Jurassic]

Hi there,

we are testing your gadget (1.4.0-RC2) on our JIRA Server 8.0.2.

This is more a question, then a proposal.

Is it possible to configure, that rejected items reduce the current scope?

On the screenshot: left: including rejected items right: without rejected items This is configured by changing the filter querry.

But, in our mind, rejected items should reduce the current scope.

What's your mind?

regards Daniel

[Danut M [StonikByte]]

Hi Daniel,

No. If you don't want the rejected items in your project scope, you have to adjust the filter query to exclude them.

Danut

[Daniel Jurassic]

Hi Danut,

please let me explain our mind:

For the upcoming sprint we have 100 people with 8 hours a day >>> capacity 800h

The team plans the full 800h of work, so it's look like all have work for the whole time.

During the sprint 200h of work were being rejected...

And after the sprint, the mangement does a resumee about the planning.

What does the managment see?

We have people for 800h of work, but we planned only 600h of work!

In this case, the management want to see we did the right during the planning und during the sprint the scope was reduced.

In our case we wourld suggest to get a single input field, which can be filled out, with the statuses, which reduce the current scope. In our case, i would fill out this field with the statuses "rejected" and "outdated", because in our case, this two statuses reduce the current scope during the sprint.

Regards Daniel

[Danut M [StonikByte]]

Hi Daniel.

For this case you should use the Team Velocity gadget. It will show both the amount of work planned (800h - Initially Committed) and the amount of work planned (600h - Finally Committed). It will also show the amount of work Done.

Take a look here: https://bitbucket.org/StonikByte/great-gadgets-add-on/wiki/Home#!team-velocity-gadget

Danut.

Please

[Daniel Jurassic]

Hi Danut,

thanks for your answer, but unfortunately this doesn't work for us.

The burndown we use ...

... bases on a complex filter querry (Scriptrunner functions)

... doesn't base on sprints (it bases on PIs)

... doesn't display the work we have done, because we dont log our work JIRA.

Any other suggestion to get to a work-around?

regards Daniel

[Daniel Jurassic]

Hi Danut,

do you have any further suggestions for my problem?

regards Daniel

[Daniel Jurassic]

Hi Danut,

on top of the above requested feature, there are two ways in our mind, how the current scope and the remaing hours will be reduced:

‌

a) the above mentioned way, meaning, something was rejected during the active sprint

‌

b) something has been moved to another release, meaning, the fixversion of the story has been changed

‌

For b) the filter should looks like : fixversion = current release OR fixversion was current release before today()

By using this filter, all issues that has ever been assigned to the current release, will be listed. I think in this case, the gadget needs an option to choose, how the current scope is defined.

‌

Additional to this, there is also the question, how the ideal burndown looks like.

Actual, the starting point of the ideal burndown is the maximum of the current scope. But, when something is rejected or moved out of the scope, the ideal burndown starting point should be [max current scope] - [original estimation of the rejected AND of the moved issues]

If the ideal burndown starting point doesn’t change while rejecting oder moving issues, the team plan 800h of work an on the first day of the sprint, they reject / move 300h, so they are under the ideal burndown for the whole sprint.

regards

Daniel