Issue analytics
Mapping custom issue types
Many companies create and manage their own issue types. SM allows mapping them to the base issue types such as Stories, Tasks, Epics, Sub-Tasks and Bugs so that the corresponding base type logic can be applied to custom type issues.
For instance, if your company implements a high-level item “Feature” that is higher in the hierarchy than Stories, it can be mapped to Epics. From SM perspective, checks related to Epics will be applied to Features.
To apply such mapping, navigate to “…” menu in any issue view → SM - Administration → “Map custom issue types” tab.
There, choose the desired base type for any of your project’s custom issue types from the dropdown and click the save button.
...
...
Using a custom Story points field
In some cases, the standard Jira Story points field is not used, and companies utilize other fields for a similar purpose. It is possible to point SM to a field that is responsible for Story points in your project.
To do this, navigate to “…” menu in any issue view → SM - Administration → “Issue Analytics” tab. There, scroll to the bottom and enter the internal Jira field ID and save the changes.
...
Checking for Acceptance Criteria as part of Story description
SM allows enabling a check that verifies that the Acceptance criteria section is present in Story description. To activate it, go to “…” menu in any issue view → SM - Administration → Issue analytics - Acceptance criteria is specified in Story Description
Mandating issues to be connected with a custom link type
In SM, it is possible to check if a certain issue type is linked to another issue type with a specified link, as part of issue checks. This setting contributes to the “Well-structured” score of each issue breakdown.
In the current release, two options are enabled:
Stories are linked to Features as “relates to”
Tasks are linked to Stories as “relates to”
To enable them, proceed to “…” menu in any issue view → SM - Administration → Issue analytics
...
In the future, the custom mapping will be implemented to allow any issue and link types.
Sprint analytics
Adjusting “lack of ownership” checks for sprints
Lack of ownership check finds all issues that have too many assignee changes. It brings valuable insights in a setup where each team member works solely on an item assigned to them. However, some teams hand over issues to other members once they reach certain status. I.e. grooming (PO) → in development (dev) → testing (QA) → documentation (tech writing) and so on.
In this case, the lack of ownership check does not add value and can be disabled. To do so, navigate to “…” menu in any issue view → SM - Administration → Sprint and Kanban Analytics and uncheck “Detect lack of ownership for issues”.