Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

A lot of users requested an easy way to create issues in bulk and link them to requirements in Confluence. We are happy to announce it is finally possible.  

When to use it

This new screen is particularly useful in the following situations:

  • If you are in a Sprint meeting and you are planning development tasks, you will select a few requirements, and create Jira issues for them.
  • If you want to associate each high-level requirement with a validation workflow, and have each single one be approved by a manager, a board of stakeholders or testers,
  • If you use Xray and you want to copy all Confluence requirements into Jira requirements.

When not to use it

It is tempting to create thousands of Jira issues with it. Don't. You will then have questions about keeping those issues up-to-date with Confluence, or across baselines. The goal is not to copy the entire Confluence database into Jira. In fact, we've limited to 100 Jira issues per batch for the moment, until we improve scaling.

  • It is much better to link a Jira issue to an entire page, rather than link an issue to every single requirement in it.
  • Creating 1 Jira issue for each requirement is a sign that you are managing the same data as requirements and as Jira issues.
  • It slows down the instance if you need to update a batch of Jira issues each time you update a Confluence page. We're happy to sell consulting services to diagnose and improve your performance, but it is a painful problem to have, and we've already optimized the product a lot. If you have the same data in Confluence and Jira, you should choose only one product.

The value of Requirement Yogi comes from annotating free text. If you keep transforming free text into Jira issues, you are making it painful for you to manage requirements. Perhaps don't create Jira issues in anticipation. Only create issues for tasks that you are going to perform during the next Sprint.

How it works

ExplanationScreenshot

Start from the Search screen, select a set of requirements and click on 'Create Jira issues'.

Note: The limit by default is 2000 requirements. It is defined by the global limit, available in the administration.

Click on the blue plus button to create a new issue template.

Template configuration:

  • Select a Jira instance.
  • Select a project.
  • Select an issue type.
  • Select a relationship.
  • Pre-configure fields.

If the checkbox 'Group all in one link' is checked, it will create one issue for all the selected requirements, otherwise, it will create one issue per requirement.

You can use some keywords to configure the issue's fields:

  • {key} will be replaced with the requirement's key.
  • {text} will be replaced with the requirement's text.
  • {baseline} will be replaced with the requirement's baseline number.
  • {relationship} will be replaced with the issue template's relationship.
  • {@any_property} will be replaced with the value of 'any_property'. Unlike the search syntax, you don't need to escape special characters here.

Note that these reserved keywords will be ignored if you create one issue for multiple requirements.

Once an issue template is created, you can re-configure it. Note that only fields are editable. 

If you wish to change the project or the Jira instance, you will have to create a new issue template.

Select requirements and Drag and drop into an issue template and click on create issues.


Once issues are successfully created, they will appear on the right sidebar.

Good to know

  • The templates limit is 30 per space.

  • You can't group more than 20 requirements in one Jira issue,
  • We truncate the summary to 253 characters because this is the Jira limit.

Right sidebar

  • When selecting a template, the right sidebar shows issues created using this template.
  • If you want to reapply the template to existing issues, drag them from the right sidebar to the template. Their fields will be updated like in the template.

Limitations

  • We support some multivalue fields such as Jira labels. However, we don't support the Components field, which looks like a Jira label but is technically different.
  • If you put a property for the labels, such as {@requirement_category}, it will be replaced.
  • If you put a property of type "list" for the labels, such as {@requirement_categories}, it will not be expanded. It will write the full list into a single label, instead of inserting n labels like one would expect.


  • No labels