Sprint report messed up after switching to Simplified Workflow


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 ?


5 answers

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

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.

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?


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:

  1. Create SCRUM project in Greenhopper with Simplified Workflow
  2. Do at least one sprint and close it.
  3. Go to configration of the Rapidboard and add a new status, let's call it Finalized
  4. Now transit the issues from Done to Finalized and remove the Done status (it should indicate 0 issues using this)
  5. 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.

I just hit this issue in JIRA 6.0.5 with GreenHopper - 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.


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.

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

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Feb 26, 2019 in Jira Software

How to prevent the propagation of unused project schemes, workflows & screens in Jira software

Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...

626 views 0 7
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you