We need this as well, this limitation in flexibility is anti-scrum. Scrum is a framework to work with and implement. Nowhere in scrum does it say there shall only be one todo and one done status. We want the timeline to correctly reflect what we are currently working on, how much is actually done, and which different statuses that are currently showing as in progress BUT ARE NOT yet started.

We are currently unable to map our development and deployment process to a board that makes sense for us and makes the burndown chart work for us. Our definition of Done is when development and testing has completed but the issue has not yet been deployed and we want the burndown chart to reflect that so we can begin deployment without affecting burndown. If this feature was implemented we should then be able to use Jira how we need to.

It would be great if we can customize the burndown based on some other status too

I have upvoted this one as well.  For teams that span multiple areas of the organization, this is very helpful, especially when using the standard reports.  

We use the Control Chart to show cycle time for our development teams.  Because we roll each team up to an overall area control chart, the columns selected on the report have no meaning (it only selects the status of the column).  Without having the second "Done" column, they are effectively penalized for the time it takes our PO and Business Partners to review and resolve each request.  For teams that have International partners that must review prior to closing, this is a big impact. 

If this is not feasible, can we at least set method for the Control Chart to be a selection - column or issue status?

I recently ran into this limitation as well, and it's a huge limitation for more complex workflows. We need to be able to differentiate between an issue that is closed/done due to code deployment, and one that is closed/done because it is either not reproducible or because the issue was resolved due to a functional resolution, or some other means that does not include code deployment. Without this functionality, we will not be able to accurately report on how our issues are resolved. Was it resolved due to an enhancement, a bug fix, or a functional workaround? Regardless, it's important that these resolved issues are removed from the Sprint Board, but searchable and filterable as resolved after the sprint is competed and a new one is created, and not simply be pushed to the next sprint. Hope this helps to encourage what seems to be an important feature enhancement for all concerned. Thanks a lot.

Marco

With all due respect, it seems to me that the solution still being of knowledge, is not a solution for the users of Jira, that is to say that all the states that represent a solution to a flow must be mapped in a column so that the graphics present themselves correctly.

This decreases the possibilities of the tool, having a great flow management, with such a simple restriction.

Is there anything else we can do, to have resolution states in separate columns?

Someone else actually mentioned the swim lanes to us earlier, but in our case we already have a set of swim lanes that divide the work into functional areas (presentation, entity management, business logic, etc.). And while we could extend those to include a status as well, we'd end up with way too many swim lanes.

I did bypass this by combining right columns and then creating a swimlane based on JQL for status, for Closed and Released issues that seems to work out well.

But I agree with all the posters on this issue that we should be allowed to configure a column as "Done (Burndown)" as we see fit.

Our current real-world board uses multiple "to-do" and "done" columns for clarity of status. For instance, at a glance, we can see how many tasks have been completed, how many tasks have been canceled, and how many tasks have been shelved.

JIRA makes seeing this separation of status extremely difficult. Note that all tasks were started at some point, and have billable hours against them, so they can not just be removed from the board, they have meaning.

So why we are allowed multiple "in-progress" columns, but not multiple "to-do" or "done" columns? In my opinion we should be allowed to create boards that work for us, and not be prescribed a specific workflow visualization. I truly hope Atlassian can and will implement this feature in the near future.

One more vote for this. We use multiple Done states and want to have them represented by two separate columns.