How to Set up JIRA for Salesforce Delivery Success

JIRA is a powerful work management tool. It is hard to imagine delivering Salesforce without JIRA or a tool like it. Other teams have also found tools such as Rally or Asana helpful. Whatever tool you use, it is critical that is supports your delivery framework and all of your activities, workflows, approvals and documentation that you need to be successful and work efficiently.

Time spent hunting down information or approvals is time wasted, and your work management tool should help your team move quickly and correctly at each step. With an effective setup, you can save a lot of time across the period of performance, and time is money. You don’t want your lead developer sifting through a Google Drive trying to find a key diagram or security matrix. This is just an additional level of effort without value added.

Instead, you will want to strive for a single source of information and a single touch, where your resources can quickly understand the status and work to be done, and move through their work with minimum level of effort and maximum efficiency.

Your JIRA setup should support your delivery framework, be easy for all to understand, and contain all of the relevant information for prioritizing, developing, testing and deploying your user stories.

To aid your team, JIRA should also link to or store supporting documentation so project resources have what they need at their fingertips and don’t have to spend time tracking information down. Here are a few things to keep in mind:

Configure Fields in JIRA: Below is a list of fields that you will find helpful in Salesforce project management. Many are standard fields in JIRA, and others can be added as custom fields. I recommend that these fields also align to your discovery tools and requirements matrix, so you can easily import this data into JIRA at the appropriate time. Once you have imported requirements data to JIRA, this is the official ‘cutover’ and JIRA should then be your single source of truth.

If you have data in JIRA already, you can export JIRA data to a spreadsheet, append additional data on stories, and import again to JIRA. It is recommended that you use only one environment at a time for your requirements tracking—either a requirements spreadsheet or JIRA, and once you have cutover to JIRA, you will no longer maintain the spreadsheet.

I prefer to start discovery with a requirements spreadsheet (matrix) in Excel and import to JIRA, as I find that it is easier to review a large number of user stories in Excel at the same time (and many client product owners are already familiar with Excel), but data can also be directly entered into JIRA.

Ready and Done: Your JIRA fields should enable you to quickly determine if a story meets the ‘Definition of Ready’ (is ready to be pulled into a development sprint), or meets the ‘Definition of Done’ (story has been developed, tested and approved).

Traceability: Your JIRA setup should allow you to trace back to your SOW, Scope, Schedule of Deliverables, and Requirements Matrix. In other words, you should be able to see how your User Stories relate to project deliverables, whether as defined in the Statement of Work or identified throughout the project. We use fields to accomplish this.

Scope Management: By tracking scope status (‘in scope’, ‘new requirement’, etc.), your JIRA setup can allow you to identify if new requirements will impact scope and should trigger the change control process.

Client Review and Signoff: Your JIRA setup can allow you to track the review and signoff from Product Owners and UAT testers. You can give your client direct access to JIRA and/or you can export your JIRA data to Excel and work through a spreadsheet with them. Either way, you will want to document their approvals and maintain as a project artifact.

Single Source of Truth: Everything the team needs to develop and test successfully should either reside directly in JIRA or be linked to JIRA. It is your single source of truth and tracking, and developers and managers should be able to rely on JIRA to immediately understand status, needs, and next steps for any and all requirements.

Consistency: Once you have determined the design of your JIRA setup, you will want to use this setup consistently across all projects. This will make it much easier for people to move between projects and become grounded in your development methodology.

Training and Coaching: Proper use of JIRA is key to getting the most out of it. It can be very helpful to create a training guide for your team and conduct a training session(s). Also, as you move forward with the project, you will want to review how the team is using JIRA, if there are any gaps or challenges, and coach the team on why and how to use it in support of the project.

Below are suggested fields that align to the Salesforce Delivery Excellence Framework. Feel free to create custom fields as needed, and to modify according to your project requirements.

JIRA Fields for Salesforce Project Success

Acceptance Criteria

• Field Type: Text- Paragraph, Custom
• Use to capture the criteria a Story must meet to pass. Best Practice: Write in GIVEN, WHEN, THEN format. Can be input for Test Cases.

Assigned To

• Field Type: Name/User, Standard
• Developer or other resource who is responsible for the work. Users must be entered into JIRA before an item can be assigned to them. It is helpful for users to include their photo in their profile.

Comments

• Field Type: Text, Standard
• User adds comments/questions to Story. Can @mention other users to alert them. It is best practice to add comments when work is done on a story.

Component

• Field Type: Picklist, Standard
• Use Component as a quick filter. It allows a way to segment/group your user stories, for example, if they relate to Sales, Service, Marketing, Data, etc. This can be very helpful during daily standup.

Date Entered

• Field Type: Date, Standard
• Auto-populates when new entry is created.

Dependency

• Field Type: Text, Custom
• What needs to be in place prior to development or testing.

Description (User Story)

• Field Type: Text, Standard
• Use the Description field to capture User Story text. As a…, I want to…, So that…

Epic

• Field Type: Text, Standard
• Epics must first be created in order to link to Story. Use Epics to group user stories. Stories are linked to Epics.

Linkages

• Field Type: Connection, Standard
• Allows user to link stories, epics, tasks, etc. Tip: Use when items are related to each other (ex: when one story is a pre-requisite for another story)

Product Owner

• Field Type: Text, Custom
• Use this field to track the Product Owner responsible for approval. This is different than Assigned To. This field provides a record of who reviewed and approved the requirement.

Product Owner Approval Date-Develop

• Field Type: Date, Custom
• Date that Product Owner provided approval for initiating development

Product Owner Approval Date-Done

• Field Type: Date, Custom
• Date that Product Owner provided approval for completed User Story.

Product Owner Approval- Develop

• Field Type: Picklist, Custom, Values: Yes, No
• Indicates Product Owner approval to proceed with development (i.e., User Story is correctly captured and ready to be developed)

Product Owner Approval- Done

• Field Type: Picklist, Custom, Values: Yes, No
• Indicates Product Owner approval on completed user story. Development completed successfully.

QA Test Case

• Field Type: Text, Custom
• This field can be used to capture the test case(s) for a story. If you are using a testing software plug-in, then you can connect the test case via a linkage instead of using this field.

Scope

• Field Type: Picklist, Custom, Suggested Values: Current, New, New-Change Request Needed, Out of Scope, Future Scope
• This is a custom field that is helpful for managing scope and backlog. It makes it easier for the team and client to see if a requirement is in current scope or if a change/change order is warranted.

SOW Task

• Field Type: Text, Custom
• You can create a custom field in JIRA called to track which SOW task the user story is associated with.

Sprint

• Field Type: Picklist, Standard
• Used to identify the Sprint that work is allocated to. This does not place work in a sprint (which is done manually), but is a guide to Sprint assignment.

Status

• Field Type: Picklist- Values defined by Org in Workflow, Standard
• Values are defined by your organization and correspond to your workflow. It is best practice to use standard workflow across all projects. Below is an example of Status values that you can use to structure your JIRA workflow. Please feel free to modify this to the needs and structure of your team. As a best practice, you want your status titles to be clear, and provide your team with a document that describes what they mean to avoid any confusion. Having the team aligned on how to use status is an important success factor in your development process.
• TO DO: Story is waiting to be picked up and worked
• BLOCKED: Story cannot move forward, may be missing key dependency or some other reason that it cannot proceed
• IN PROGRESS: Story is being worked
• QA READY: Development has been completed and story is ready for QA testing
• QA COMPLETE: Story has been tested by QA and has passed
• READY FOR UAT: UAT test scenario has been documented and story is ready for User Acceptance Testing by Business
• READY FOR PROD: Story has passed QA and UAT testing, meets the Definition of Done and is ready to be deployed to higher environment
• DONE: Story has been deployed to higher environment (either UAT or Production, depending on the release plan)

Supporting Documentation

• Field Type: Single URL, Custom
• Use this field to store a link to supporting documentation. If you use Confluence for document storage, then you can provide the Confluence link. Examples of documentation include: Configuration Workbook, Security Matrix, User Matrix, Architectural Diagrams, Architecture Design Document, etc. It is important that wherever you store documentation, it is accessible to the delivery team.

Technical Specifications

• Field Type: Text- Paragraph, Custom
• Technical information and instructions for what needs to be developed.

Title

• Field Type: Issue Title Text), Standard
• User Stories are called 'Issue's in JIRA. This is the title (or name) of the issue.

T-Shirt Size

• Field Type: Picklist, Custom
• T-Shirt Size can be used for initial relative sizing. Suggested Values: XS, S, M, L, XL, XXL

UAT Comments

• Field Type: Text-Paragraph, Custom
• Comments or questions from UAT Tester

UAT Pass

• Field Type: Select List-Single, Custom
• Values: Yes, No

UAT Pass Date

• Field Type: Date, Custom
• Date that User Story passed UAT

UAT Test Scenario

• Field Type: Text- Paragraph, Custom
• UAT Test Scenario/Test Case

UAT Tester Name

• Field Type: Text, Custom
• Name of UAT Tester

If you would like help with your JIRA setup and how to align it to your delivery methodology, feel free to send me a note or schedule some time.