nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Sprint report messed up after switching to Simplified Workflow

JIRA Autobot

Hi,

I switched our project to Simplified Workflow and then removed the statuses not needed but now the Sprint Report is all messed up because of this. I can "repair" this by putting the old statuses back so the statistics are correct but then those statuses also show up so they can be used by people and i don't want that.

Is there anything i can do about it ?

/donnib

Accepted answers

All comments

boardtc

Are you speaking about open / reopened / in progress / resolved / closed? Which ones do you want restricted?

JIRA Autobot

I used to use my own workflow in the Greenhopper (rapidboard), everything was working fine. We have completed many sprints with that workflow. When you finalize a sprint in Greenhopper it "freezes" which issues were done and which not and that list is created from the workflow like what state makes an issue complete and so on. Because i have changed to the new workflow (simplified) then the Sprint Reports wants to use the old information which is not available anymore because those statuses are gone so the sprin reports/burn down charts and velocity charts are all messed up.

It seems that after all those reports eventhough finished are still using information from the workflow so if you change it then all your historical data are "destroyed".

The only way i can have my old stuff ok that is to leave the new statuses in place which is not what i need because i WANT to get rid of them and change to the new ones.

What i wish was that i could change the status of the old ones to the new ones so that all the old data would be ok but i there is no support for that in Greenhopper so i am asking for help.

Hope this made it more clear.

sclowes

I think there was a bug with this in previous versions of GreenHopper because we were using status ids rather than names. I think if you use the latest version of GreenHopper with JIRA 5.2 this won't happen any more as long as your new workflow still includes statuses with those names. Could that work?

Cheers,
Shaun

JIRA Autobot

Hi Shaun,

Nice to see you around

Unfortunnately this is still a bug in the latest Greenhopper 6.0.8 which we are using.

It's extremely easy to reproduce:

Create SCRUM project in Greenhopper with Simplified Workflow
Do at least one sprint and close it.
Go to configration of the Rapidboard and add a new status, let's call it Finalized
Now transit the issues from Done to Finalized and remove the Done status (it should indicate 0 issues using this)
Now check the Sprint Report / Burndown chart / Velocity report from the Sprint that was closed in step 2 and you will see it's not correct because the Done status is not there anymore. What seems to happen is that the before change "Issues completed" in the Sprint Report get's kicked to the "To-Do" status hence they are shown as "Not Completed".

You say in your last line "as long as your new workflow still includes statuses with those names". That's exactly what i would like to avoid. If this is the case then everytime you change statuses in a workflow you need to keep the old ones which means that the user will be able to use them. That is no go for me. As i pointed out, if i keep the old statuses together with the new ones the historical data is ok but again not a solution i can use.

I would be happy if there were some kind of work around before (if) you fix this. I guess the best fix would be to warn the user when he removes a status which is used in historical data and that you give him the option to fix this. One would need to state what the old statuses are in the new workflow.

Jan Nielsen

I just hit this issue in JIRA 6.0.5 with GreenHopper 6.2.5.1 - after migrating our JIRA issues to our new workflow, my Sprint Velocity report looks very, very bad. Before the migration our completed exceeded our committed for the last half-dozen sprints but now our completed reporting as a tiny fraction of our committed for all completed sprints. This is very, very bad.

I'm guessing I need to write some SQL to fix this issue since there are no responses since November of last year...?

Any help would be greatly appreciated.

Jan

unknown

I also have this problem. Are we limited to direct DB updates to fix this? It seems the fix would be to update the time the issues changed to the new workflow states back to the days within the sprints.

Heidi Smith1

Did you ever find an answer? Any idea what DB update you would need? We are using hosted Jira, so DB update is more difficult