On this page:

Overview

Workflow Essentials for JIRA supports users through the whole process starting from the first workflow step: Creating Issues and Sub-Tasks. In JIRA you can define global or Context-specific default values, but not for system fields, and only globally.

With the "Default Values" Extension you can define Default Values for system fields like summary and description and custom fields so that they will appear directly on the "Create Issue" / "Create Sub-Task" screen.

Note that you can also define default values on transitions with our "Set / Update Value Post Function".

How to configure

The configuration page of this extension can be found under Admin > "Add-ons" > "Default Values for Create Screens" (vertical menu). There you can set your default values for all your fields. Select the appropriate project and issue type and put in your default values. You can also define global default values by choosing the option "All projects".

For example, set a default template for all User Stories you create in your project. So you can make sure, that the users always using the same structure for filling out your fields.

That's it! Now you can create new issues and it looks for example like this.

Supported system fields:

• Summary
• Description
• Environment
• Due Date
  • supports a fixed date or a variable expression like +7d (certain days from now, as known from Jira markup)  
• Original Estimate
  
  

Supported custom fields:

• Text
• Number
• Multi User Picker
  
  

Supported screens

• Issue Create Screens and 
• Sub-Task Create Screens

Templates

In this section you find some templates you can copy or use as starting point. Two common uses cases are defining templates for User Stories and for Bugs.

User Story Templates:

Summary

• As a TYPE_of_user, I want some_GOAL so that some_REASON
• Alternative Summary (for quicker Overview in the backlog): Describe your GOAL

Description

As a TYPE_of_user, I want some_GOAL so that some_REASON
*Acceptance Criteria*


* every Detail goes on a new Line
* Do not hide requirements in a subordinate sentence
* include background information on the 'why' below


*Not in this story*
* things which are nice to have 
* or possible extensions 


*Background Information*
Customer E-Mails, Discussions, Why do we build it, Who asked for this feature, ...

Bug Templates

Summary

• A concise description - no narrative language.

Description

*Steps to Reproduce*
Step by step instructions on how to reproduce this bug.
Do not assume anything, the more detailed your list of instructions, the easier it is for the developer to track down the problem!

*Actual Behavior*
Type what happens when you follow the instructions.  This is the manifestation of the bug.

*Expected Behavior*
Type what you expected to happen when you followed the instructions.  This is important, because you may have misunderstood something or missed a step, and knowing what you expected to see will help the developer recognize that.

*Troubleshooting/Testing Steps Attempted*
Describe anything you did to try to fix it on your own.

*Workaround*
If you found a way to make the program work in spite of the bug, describe how you did it here.