Is there anyone here transitioned from Pivotal Tracker to Jira?

[Jay Pawar]

Hello friends, we are looking to transition from Pivotal Tracker to Jira Software. I was the lucky one to give this responsibility so I wanted to reach out and see if I can get a step by step process to this transition. What is the thing I should keep in mind with workflow and permissions? 

[Jack Brickey · Accepted solution]

@Jay Pawar,

as an FYI it is always best to start a new thread for separate questions and often a search will find the answer but not always. 

With that said, you can create a quick filter and use that to filter on statuses but not ordering. TBH, I never use the backlog to view the active sprint as I find it less useful than viewing on the active sprint board. You can also add the status on the card to display on backlog. 

BTW,i think if the issue is done it disappears from the backlog but not sure. 

[Surya]

Do you find a solution? i am also looking for transition from Pivotal to Jira but havent find any aolution 

[Jack Brickey · Accepted solution]

@Jay Pawar, that is a broad requestrian so unsure if you will get any takers or not. While I have migrated from other tools Pivotal is not one. While waiting for a response I would recommend entering Pivotal Tracker into the search here as there are a handful of discussions already. 

[Jay Pawar]

Thank you

[Jay Pawar]

@Jack Brickey Thank You for your reply. I look it up but most of the posts are about imports. I think one thing I can say is it doesn't have to be Pivotal Tracker to Jira. It can be CA Rally to Jira or VersionOne to Jira transition as long as I have some steps to follow.  

[Jack Brickey]

In reality the Import ultimately will drive this project. At a very high-level here is what i have done and recommend:

1. Contemplate your current solution. Write down what is good that you really want to retain. Note what is undesirable and don't repeat it in Jira.
2. Construct the test project that you can later delete because invariably the import won't go perfect the first time.
3. Build your workflow. If you are fortunate to be able to stick w/ the default workflow great! If not work on building it.
4. Create your users. This can be done as part of the import but it can get messy depending on your situation.
5. Start to work on the Import. If there is an import function for Pivotal Tracker great. If not you will be looking at CSV import. Export a sample of issues from the current system just to get the structure. At this point you can use this to create custom fields as needed to map what you want. You may not want all fields to carry forward.
6. Import the sample into the project. You will want to place care w/ the dates. That seemed to trip me up several times.
7. Review the imported data for errors, undesirable results etc., tweak things and perform another round of import. 
8. Once you get your import working the way you want and are happy with the basic project flow you have a couple of options. either a) delete all issues and use the current project or b) create a new project and leverage your final workflow and customer fields, etc from the test project.
9. Import your data into the new project and perform any cleanup
10. At this point you should be ready to bring the team onboard. You may wish to have one or two user give it a try and then take in their feedback.
11. Build a project for Jira requests. Live w/ what you have for a few weeks before making too many changes. Let the requests for change build up and maybe use Jira voting to establish what needs changing first.

hope this helps. i highly recommend reviewing all of the documentation Atlassian offers on getting started.

[Jay Pawar]

@Jack Brickey Hello Jack just wanted to take a few mins to thank you for your help and suggestions. We are set up and now using Jira. 

[Jack Brickey]

Great. If this answered your need please consider accepting by clicke the check mark next to the votes icon. 

[Jay Pawar]

@Jack Brickey Done! and now I have another question and that is... 

Is there a filter to organize the active sprint section in the backlog (not by ranking but by statuses) so we can eyeball which tickets are done vs. not? Status tags instead of Epic tags (ie: QA Testing, In Progress, etc.)