standard jira client - slsvn.indra.es · standard jira client use guide – practical case 5 1...

Use Guide

STANDARD JIRA CLIENT

(Practical Case)

Version 3.0 Madrid, July 2018

Standard JIRA Client Use Guide – Practical Case 5

1 OBJECTIVE 4

2 BASIC STANDARD SOLUTION 4

User Profiles 4 2.1

Types of issue 5 2.22.2.1 Functional Support 5 2.2.2 Corrective Maintenance 6 2.2.3 Feature Request 7 2.2.4 Big Feature Request 8 2.2.5 Epic 9

3 PRACTICAL CASE OF A CORRECTIVE MAINTENANCE ISSUE 10

Creating an issue by the client 10 3.13.1.1 Field tab 12 3.1.2 People tab 14 3.1.3 Dates Tab 14 3.1.4 Key Tab 15 3.1.5 Estimation Tab 15

Parameters and windows of the Issues of JIRA-CLIENT 17 3.23.2.1 Header of the issue 17 3.2.2 Issue Menu 18 3.2.3 Details Section 23 3.2.4 Description Section 24 3.2.5 Activity Section 24 3.2.6 People section 24 3.2.7 Dates Section 25 3.2.8 Agile Section 26

Progress of the issue performed by the support team and monitoring by the client 28 3.33.3.1 Reopening a task by the client 34 3.3.2 Acceptance and closing of a task by the client 35 3.3.3 Cancelling Tasks 38 3.3.4 Deleting tasks 40

4 PRACTICAL CASE OF A FEATURE REQUEST 42

Creating a Feature Request by the client 42 4.1

Parameters and Windows of a Feature Request 42 4.2

Progress of the issue performed by the support team and monitoring by the client 43 4.3


5 EPIC TYPE ISSUES IN JIRA-CLIENT 52

Add Issues to an Epic 54 5.1

Remove Issues from an Epic 54 5.2

Complete and reopen an Epic 55 5.3

Reopen an Epic 56 5.4

6 APPENDIX 1 57


1 Objective

The objective of this document is to describe several practical cases applied to the Standard JIRA Client solution and in this way study their work cycles from the creation of the issue, the evolution from the support team and the monitoring by the client.

It will also include the types of profiles defined to interact with the tool as well as which parameters and configuration windows are included according to the type of issue. The last section will be focused on the use of Epic type issues.

2 Basic Standard Solution

Basic Standard JIRA Client is one of the solutions available at JIRA for GA Services that responds to the needs of operations when it is necessary to manage the issue with the Client. The access and level of permissions on the tool are defined by the following profiles.

User Profiles 2.1

The User of the service is in charge of creating the issues (Functional Support, Corrective Maintenance, Feature Request or Big Feature Request). This user will track the progress of the tasks and can accept or reject the actions and work performed by the Indra support team.

The Person responsible for the service is a profile projected to perform supervision and monitoring tasks. It can also create new issues.

Read-only: It is a read-only profile projected to the client users, which allows querying the evolution of the project issues, but it doesn’t allow carrying out any operational activity on it; that is to say, it will neither allow creating issues nor making changes or any kind of transitions.

Administrator: is a profile projected to perform administration tasks.


Types of issue 2.2

The types of issue defined in JIRA CLIENT are the same as the three types of issues that the client can perform (Functional Support, Corrective Maintenance, Feature Request and Big Feature Request), and the tasks of Epic type that allow grouping several feature type Issues.

To better understand how the different types of issue work, the following sections describe their features and show their workflows.

2.2.1 Functional Support

Definition: Activities to solve queries and extract information by means of loading service, processing or massive data collection, etc.

The workflow for this type of Issues is shown below.

Image nr. 1 Functional Support


2.2.2 Corrective Maintenance

Definition: Carrying out the appropriate modifications to correct an incorrect operation in the systems maintained. Any software errors that occur in a production environment accepted by the customer. It includes errors that do not require software delivery.


Image nr. 2 – Corrective Maintenance


2.2.3 Feature Request

Definition: Improvement and evolution of small complexity or size of the existing applications, including new functionalities, adapting the existing ones and improving their overall quality.


Image nr. 3 – Feature Request


2.2.4 Big Feature Request

Definition: Improvement and evolution of high complexity or size of the existing applications, including new functionalities, adapting the existing ones and improving their overall quality.


Image nr. 4 – Big Feature Request.


2.2.5 Epic

Definition: Its main characteristic is to allow the grouping of Issues of feature type that can be planned in different sprints without losing their functional link. This enables to manage standard project operations with Agile methodology.


Image nr. 5 - Epic

When there is integration between a Standard JIRA-Client and JIRA MInd, it will be possible to create Issues of the Epic type from the client, which will allow the management of operations of Standard projects and Approvals with agile methodologies.

Simultaneously with the creation of an Epic type issue in a JIRA-Client, a similar issue will be automatically generated in the JIRA-MInd. The Epic will be managed from the JIRA-Client, both at the level of the Agile dashboard and at the level of the issue, replicating any changes made from the client to the Jira MInd. This will allow continuous monitoring both from the client Board client and from the MInd.

It should be noted that, in order to query and add a new issue on an Agile board it will be necessary to have access permissions to the board.

A practical case explaining how to work with Epic type issues can be seen in section Create and edit an Epic in Jira User Manual.

.


3 Practical case of a Corrective Maintenance issue This section will explain in detail:

The creation process of an issue from the client and later editing The evolution by the support team.

Its monitoring from the client.

The fields related to the creation of an issue are common to all types of issue. Instead, their status may vary through the life cycle of the issue depending on their type.

Creating an issue by the client 3.1

By clicking the Create button located in the upper menu of the tool of JIRA-Client, the process to create a new issue will trigger. (Image nr. 6).

Image nr. 6 - Option Create in the upper menu of JIRA-CLIENT.


The window Create Issue allows the configuration of data related to the issue. (Image nr. 7).

Image nr. 7 - Window Create issue.


The fields (listed in image nr. 7) to be completed are the following:

1. Project: It allows selecting the Project from the dropdown menu Project. The data marked with an asterisk in red (*) are mandatory fields.

Image nr. 8 – Selection of Project and Issue Type.

1. Type of Issue: It allows selecting from the Type of Issue dropdown menu, which Type of Issue is going to be created. A Corrective Maintenance type issue has been selected for this example. (*) Mandatory field.

Image nr. 9 – Issue type selection.

Then, the fields included in the issue tabs that are detailed below must be completed.

3.1.1 Field tab

Following the reference of the ‘Image nr. 7 - Window Create Issue’ the fields included are the following:

1. Summary: It summarizes the issue or problem.

2. Description: A more detailed description. It can be minimized clicking the icon:

3. Component(s): Dropdown menu that allows selecting the component on which we are working.

4. Priority: It allows selecting the priority according to the criteria from highest to minor priority: Blocking, Critical, Minor or Trivial.

Image nr. 10 – Priority.

Note that once the issue has been created, it will only be possible to change its type as long as it remains in the New status. Then, it will no longer be possible.


5. Criticality: As the previous point, it allows selecting the criticality of the problem based on the following criteria: None, High, Medium or Low.

Image nr. 11 - Criticality.

6. Tags: It allows selecting an existing tag or creating a new one that can be identified in subsequent searches.

7. Attachment: By clicking the button: Choose files we can attach information to complement the issue description.

8. Issue creation date: will be the date that indicates when the issue was made.

9. SLA Exclusion Indicator: It allows indicating whether the SLA indicators are excluded by selecting the dropdown option: Yes.

10. SLA Exclusion Reason: When we select exclusion of the indicators (previous field), it allows describing why these indicators are excluded.

When more than one issue is generated, the checkbox: next to the Create and Cancel button can be selected.


3.1.2 People tab

It allows selecting the responsible person assigned to the issue by using the Assignee dropdown menu. If no selection is made, the application will automatically assign the person responsible for the project (defined from the Project administration). Pressing the quick option: Assign to me the issue will be self-assigned.

Image nr. 12 - People Tab.

3.1.3 Dates Tab

It allows selecting from the client the following enabled dates:

Due Delivery Date

Committed Response Date: Based on the client schedule.

Image nr. 13 - Dates Tab.

Disabled dates:

Planned Start Date: it will not be filled in, as the planning will be made by the Indra support team.

Planned End Date: it will not be filled in, as the planning will be made by the Indra support team.


3.1.4 Key Tab

It allows inserting the client Project key.

Image nr. 15 - Key Tab.

3.1.5 Estimation Tab

It allows completing the estimation data:

Estimated Hours: It allows including the estimation data of the task. Invoiced Hours: It allows including the invoicing data of the task.

Image nr. 16 – Estimation Tab.

In order to finish the process of creating the Issue and after completing the fields, at least the fields marked with a red asterisk (*) that are mandatory, press the Create button to generate the new issue.

A pop-up message will be displayed indicating that the issue has been successfully created. The message is a hyperlink that links to the newly created issue.

Image nr. 17 – Message confirming that the issue has been created.


In the Issues – Recent Issues option in the upper menu of JIRA-Client it can be seen that the newly created issue appears in the first position.

Image nr. 18 - Issues-Recent Issues.

In addition, by means of the issue key, it will be possible to locate it from the search box of the upper menu of JIRA-CLIENT (Image nr. 19).

Image nr. 19 - Option Search in the upper menu of JIRA-CLIENT.

If the user is the Assignee or Reporter of the issue, he/she can be located from the gadget Assigned to me included in the Dashboard of JIRA-CLIENT. (Image nr. 20 - Gadget: Assigned to me).

Image nr. 20 - Gadget: Assigned to me in the Dashboard


Parameters and windows of the Issues of JIRA-CLIENT 3.2

All the information of each issue created in JIRA-Client is gathered in a window as shown in the following Image nr. 21.

Image nr. 21 – Window of an issue created in JIRA-Client.

Taking as a reference the previous image (Image nr. 21) each of the numbered sections is explained below.

3.2.1 Header of the issue

In the upper part of the window (Nr.1 - Image nr. 21 – Window JIRA-Client issue) the data used to identify first the issue are presented, such as the identifying icon of the project, the name of the project, the code (Key) assigned to the issue and the title assigned to the created issue.

Image nr. 22 – Issue header


3.2.2 Issue Menu

The issues of JIRA-Client have a menu (Nr.1 - Image nr. 21 - Window JIRA-Client issue) at the top that allows different actions on the issue.

Image nr. 23 - Menu of a JIRA-Client issue

According to the image nr. 23, the options from left to right are the following:

3.2.2.1 Option Edit in the issue menu

The Edit option opens the issue edit window (see image appendix 1) which allows the modification of some fields that were completed in the creation as well as other new fields that are included in the window.

Below we analyse these changes:

3.2.2.1.1 Field Tab

The fields included are practically the same as in the creation window (Image nr. 7 - Create Issue Window), except for the following differences.

1. All fields but the field Type of Issue can be modified, as once the issue has been generated, it cannot be modified.

Image nr. 24 - Not enabled option. Type of Issue.

2. The following fields (Image nr. 25) are added to the Field Tab: Deliveries: Number of deliveries until the issue is approved. Non-editable field. The

support team will be in charge of updating it. Defects: Number of defects identified during the user tests. Non-editable field. The

support team will be in charge of updating it. Comment: Text field that allows adding a comment from the client, that may refer

to some modification or change added.


Image nr. 25 - Fields Tab – Edit Issue Mode.

3.2.2.1.2 People Tab

It shows the person assigned to the issue. It allows assigning a new Assignee and adding a Comment in the text box. (Image nr. 26).

Image nr. 26 - People Tab – Edit Issue Mode.


3.2.2.1.3 Stop Tab

This new tab adds the following fields that will be only modified by the support team and by the client in specific situations:

Stop Reason: It allows adding stop information from JIRA-MInd to JIRA-Client, but only when its value is Client Doubts.

Stop Comment: It allows adding a stop comment from JIRA-MInd to JIRA-Client, but only when its value is Client Doubts.

Reject Reason: It allows adding reject information from JIRA-MInd to JIRA-Client, but only when its value is Client Doubts.

Continue Comment: It allows adding a stop comment from JIRA-MInd to JIRA-Client, but only when its value is Client Doubts.

Reopening Reason: It will be enabled to add information when a transition is made from JIRA-Client from the Delivered to the Reopen status.

Reopening Comment: It allows recording a comment in the Reopen transition made from JIRA-Client.

Comment: It allows recording all the desired information during the progress of the work.

Image nr. 27 - Stop Tab – Edit Issue Mode.


3.2.2.1.4 Dates Tab

The Dates tab in edit mode adds the following fields:

Start Date: It allows adding a Start Date to the support team (JIRA – MInd).

End Date: It allows adding an End Date to the support team (JIRA – MInd). Comment: Unrestricted text box that allows recording any comments during the

progress of the work.

Image nr. 28 - Dates Tab – Edit Issue Mode.

3.2.2.1.5 Key Tab

It adds a Comment text box that allows recording any comments during the progress of the work.

3.2.2.1.6 Estimation Tab


3.2.2.1.7 Service Commitment


Up to this point, it would be the issue edit mode, option Edit of the issue menu. The following section will be Details.


3.2.2.2 Comment option in the issue menu

It allows adding comments to the issue.

3.2.2.3 Assign option in the issue menu

It allows selecting a new assignee or person responsible for the issue tracking.

3.2.2.4 More option in the issue menu

The possible actions of this dropdown menu include: To show the issue in the Agile Board, To classify the issue in the list of issues, To Attach Files or Screen Captures (see section Send attachments from Jira User Manual).

), To Notice or to see the Watchers, To Create a Sub-task, to attach a Link (*), To clone the issue, or to add Tags. (Image nr. 29 More submenu of a JIRA-CLIENT issue).

Image nr. 29 - More submenu of a JIRA-Client issue.

(*) A Link of Web type can be created, linked to an URL address, or the issue can be linked to other issues through a dependence relationship that will be indicated in the field This issue. The issue, to which the link is performed, is indicated in the field: Issue that can be selected from the attached dropdown menu that shows the search history, or writing the issue key.


3.2.2.5 Delete option in the issue menu

To the right of the More menu the possible transitions that the user can make on the issue depending on its status will be displayed.

3.2.3 Details Section

The Details section (Nr. 3 in Image nr. 21 - Window JIRA-Client issue) shows the main parameters of the issue and its current status.

When the issue has been estimated, and the client key and his/her data have been indicated, as well as the SLA exclusion, three new tabs will be seen at the bottom of the Details section. (Image nr. 30).

Image nr. 30 – Details section

They are the following:

Field Tab: It points out whether the request by issue or project type is excluded from the Service Level Agreements (SLA) and it also includes an attached comment explaining the reason. Another relevant information is the External Issue ID, which refers to the issue associated in Jira-MInd.

Keys: It shows the key of the Project and the Reporter data such as Name, Telephone and email.

Estimation: It shows the Estimated and Billed hours defined in the issue.

New fields are added to this section, providing relevant information such as:

Status: It points out in which status is the Issue within the cycle.

Resolution: It points out whether or not the Issue is resolved.

When the issue appears in a New status, it can change to Deleted pressing this button.


3.2.4 Description Section

It describes in a detailed manner the problem or specific needs of the issue. This section can be combined with the possibility of attaching documentation from the More menu of the top menu of the issue. (See section: Attach files).

3.2.5 Activity Section

In the lower part of the issue window is located the section Activity. (Image nr. 31 - Activity).

Image nr. 31 - Activity

This section contains several tabs with information of the issue changes. The image shows the tab Comments that displays the comments inserted from JIRA-CLIENT and those inserted by the Indra support team in the issue associated with JIRA-MInd.

History of changes: it shows chronologically the changes made in the issue. Activity: It shows the updates made in the issue. Transitions: It shows the transitions made throughout the issue.

All: It shows all the previous data.

3.2.6 People section

The People section (as in the image below) shows the Assignee and the Reporter of the issue. Additionally, the Watchers section lets adding those users that should receive notification about the changes in the issue.

Image nr. 32

Watchers may be added to receive notifications, e.g. when the status changes in the issue, a comment is added, comments are uploaded to the issue, etc.

To add a watcher, click on the watcher indicator number (see illustration below). In the pop-up box, start typing in the field: Add Watchers and select the new watcher. (Image nr. 33 - Add Watchers).


Image nr. 33 – Add watchers.

3.2.7 Dates Section

The top right part of the issue window shows the Dates section, which includes all the relevant dates around the issue. (Image nr. 34 - Dates).

Image nr. 34 - Dates

The dates defined for an issue are detailed next:

Name of the field Description

Due Agreed end date.

Created Date when the issue was registered.

Issue creation date Date added manually showing the real date of the client issue.

Committed Response Date Expected and agreed date to focus on analysis or start of the activities to resolve the issue.

Planned Start Date

For Features, date required when changing to the Estimated/Planned status. For Corrective Maintenance and Support, is the date expected to change to the In Progress status.


Planned End Date Mandatory when changing to the status Estimated/Planned. It will take by default the value of Due. It can be however modified afterwards.

Start Date

Automatic. It is the real start date, that is, the date that the status has changed to In Progress. Although it is a date assigned automatically, it can be changed afterwards by the Assignee profile.

End Date

Automatic. It takes the value of the time when the issue status changes to Delivered. Indeed, it is the real date of the issue delivery. Although it is a date assigned automatically, it can be changed afterwards by the user with the profile Assignee.

Resolved Automatic. It takes the value of the time when the issue status changes to Closed, that is, the date when the issue has been closed.

Updated Automatic. Date when the last change was performed.

Attended Automatic. Date when the Indra support team registers the beginning of the work associated with the issue.

3.2.8 Agile Section

It allows seeing the issue in an Agile Board when pressing on the link: See in Board.

After clicking on this link, the Go to board window allows selecting in which board where the issue appears we want to see it. (Image nr. 35 – Go to Board).

Image nr. 35 – Go to Board

Then, the Agile board that includes the issue will open. As it is a newly created issue, it will appear in the board Backlog. (Image nr. 36 - Example of Agile Board.).


Image nr. 36 – Example of Agile Board


Progress of the issue performed by the support team and 3.3monitoring by the client

Indra Support team is in charge of managing the issues created automatically in JIRA-MInd starting from the creation of Issues from JIRA-CLIENT.

The person responsible for the Component receives an email notification for each new created issue. (Image nr. 37 – Notification via email).

Image nr. 37 – Notification via email.

Other users of the Project can also detect the creation of the new issue in the section: Activity Flow of the JIRA Project. See section: Parameters and windows of the Issues of JIRA-CLIENT section: Activity. (Image nr. 38).

Image nr. 38 – Activity flow.


The issue created in JIRA-CLIENT will correspond to one of the products of Indra Service operations (Functional Support, Corrective Maintenance, Feature Request or Big Feature Request).

The person responsible for the component selected in JIRA-CLIENT can assign the issue to a user, who will be the new person responsible for its management and monitoring. For this, press the button Assign in the issue menu. (Image 39).

Image nr. 39 – Assign from the upper menu of the issue.

A Comment can be included in the issue. The user will receive it by email with the notification informing that the issue has been assigned to him/her (Image nr. 40).

Image nr. 40 – Add comment when assigning the issue.

After assigning the Issue, it can be verified in the section People (Image) of the issue window that the name of the new responsible user will be present in the field Assignee. (Image nr. 41).

Image nr. 41 - Assignee.


In case the user accessing JIRA-CLIENT is the one who has to take charge of the issue, the button Assign to Me in the Assign option of the menu can be used in order to self-assigning the issue. (Image nr. 42).

Image nr. 42 – Self-assigned.

The management of the issue will be done as any other Service issue, that is, following the workflow and advancing through the issue resolution process.

From the New status of the issue, the transition Analyse (Image nr. 43) indicates (from JIRA-MInd) the beginning of the PRELIMINARY STUDY. From JIRA-MInd, it will be possible to add a comment related to the transition.

Image nr. 43 - Transition Analyze

After the previous step, the client will see in JIRA-CLIENT that the associated issue has changed to the PRELIMINARY STUDY status. Additionally, the user of JIRA-CLIENT assigned to the issue, and the reporter will receive an email notifying the status change to PRELIMINARY STUDY. (Image nr. 44).

Image nr. 44 - Change to Preliminary Study in JIRA-CLIENT

This status change can also be seen in the section Activity of the issue in JIRA-CLIENT.


Image nr. 45 – View of the status change in the activity section.

In JIRA-CLIENT, just as they can receive a comment included in the issue, the user responsible for the issue will also be able to add a comment to the issue by clicking on the Comment button at the bottom of the issue window.

Image nr. 46 – Button to add a comment.

From JIRA-MInd, when the support team is going to start the work associated to the issue, the transition Work in progress must be accomplished (Image nr. 47). This transition will have associated the mandatory modification of the fields: Due Delivery Date, Fix Version and Component from JIRA-MInd.

Image nr. 47 - Transition Work in progress.


In JIRA-CLIENT it can be verified that the issue has changed to the status: WORK IN PROGRESS, which informs that the work in the solution is in progress (from JIRA-MInd). (Image nr. 48).

Image nr. 48 - Status change to Work in progress in JIRA-CLIENT.

When Indra support team (JIRA-MInd) finishes the development of the solution, they will perform the transition Test to show that the test phase starts. (Image nr. 49).

Image nr. 49 – Transition to the Test status.

This transition Test changes the status of the JIRA-MInd issue to Testing. (Image nr. 50).

Image nr. 50 – Status change to Testing in JIRA-CLIENT.

However, in JIRA-CLIENT the status will not change, as this is a work of the MInd support team.


Once the test phase (Testing) has successfully finished, the support team (in JIRA-MInd) runs the transition Deliver.

Image nr. 51 - Transition Deliver.

The transition Deliver in JIRA-MInd leads to the status Delivered. (Image nr. 52).

Image nr. 52 – Status Change to Delivered in JIRA-MInd.

The equivalent in JIRA-CLIENT will be the change to the status DELIVERED. (Image nr. 53).

Image nr. 53 - Status change for Delivered in JIRA-CLIENT.

This way, the client will be aware that the work is fully completed. Then, the work performed from the Client side will be evaluated to accept them through the transition: Close Issue (Image nr. 54).

Image nr. 54 - Transition Close issue in JIRA-CLIENT.

Alternatively, reject them through the transition: Reopen. (Image nr. 55).

Image nr. 55 - Transition Reopen in JIRA-CLIENT.


3.3.1 Reopening a task by the client

As mentioned in the previous point, using the Reopen transition button of the issue in JIRA-CLIENT, the client can reject the issue that has been delivered by the Indra Support Team (in JIRA-MInd).

In the popup window (Image nr. 56) of the Reopen transition, the client must classify the reason for the reopening, selecting one of the options of the field Reopening Reason.

Image nr. 56 – Select the Reopening Reason in the Reopen window.

It is also required to insert a comment explaining the detailed reasons for reopening, as displayed in the image below (Image nr. 57).

Image nr. 57 – Add reopening comment.


Once this transition is accomplished in JIRA-CLIENT the status will change to: REOPENED. (Image nr. 58).

Image nr. 58 - Reopened status change in JIRA-CLIENT.

After that, the status of the issue associated in JIRA-MInd changes to Reopened (Image nr. 59) and the support team will be informed that the client has rejected the deliverable and hence rework is required.

Indra support team (JIRA-MInd) can view in the Stop/Reject tab of the issue the client reasons and the comments for reopening the issue.

Image nr. 59 - Status change to Reopened in JIRA-MInd.

3.3.2 Acceptance and closing of a task by the client

In order to accept the deliverable, the client has to press the button: Close Issue. (Image nr. 60).

Image nr. 60 - Transition Close issue in JIRA-CLIENT.

The Close Issue transition window requires the user to indicate the type of resolution applicable to the issue. For this, select one of the options of the field: Resolution. (Image nr. 61).


Image nr. 61 - Options of the Resolution Field.

The date of close (field End Date) is updated automatically in the issue resolution window, and a comment related to the closing of the issue can be added. (Image nr. 62).

Image nr. 62 - Add comment in Close issue.

The issue in the status CLOSED will be displayed at the end of the close transition, in JIRA-CLIENT. (Image nr. 63).


Image nr. 63 - Change to status Closed in JIRA-CLIENT.

The support team will accordingly view the associated issue in the status Closed. This way they will know that the client has accepted the work done. (Image nr. 64).

Image nr. 64 - Change to status Closed in JIRA-MInd.

If any nonconformity is detected from the client after closing the issue (JIRA-CLIENT), by means of the Reject transition button, the client can reopen the issue. (Image nr. 65).

Image nr. 65 - Transition Reject from JIRA-CLIENT.


3.3.3 Cancelling Tasks

If the work done on an issue has stopped, the status will be now Stop. (Image nr. 100). To do this, at any stage of the process, the Indra support team can execute the transition of the same name from the dropdown menu Workflow selection Stop.

Image nr. 66 - Change to Stop from JIRA-MInd.

The reasons of this discontinuation must be pointed out in the transition window in the field Stop Reasons. A related comment should be filled in in the Stop Comment field. (Image nr. 67).

Image nr. 67 - Indicate the stop reason and a stop comment.

Once in the Stop status, if the issue finally is going to be closed permanently without concluding the work, the transition Cancel must be called. (Image nr. 68).

Image nr. 68 - Transition Cancel for permanent close by the support team.


The close reason should be indicated in the transition. (Image nr. 69).

Image nr. 69 - Complete field Resolution Comment.

Likewise, the issue in the JIRA-MInd remains with the status Closed and it shows the value Invalid in the field Resolution. (Image nr. 70).

Image nr. 70 - It changes to status Closed – Resolution: Invalid in JIRA-MInd

In JIRA-CLIENT, the associated issue remains with the status CLOSED and it shows the value Invalid in the field Resolution. (Image nr. 71).

Image nr. 71 - It changes to status Closed - Resolution: Invalid in JIRA-CLIENT.


3.3.4 Deleting tasks

Sometimes a task can be created by mistake (e.g., duplicate is inserted). In this case, from JIRA-CLIENT, the Delete transition can be performed to mark the issue as erased. (Image nr. 72).

Image nr. 72 - Transition Delete.

In the transition window (Image nr. 73) is requested an explanatory comment of the reasons to delete the issue.

Image nr. 73 – Window Delete.


Once the transition is accepted, the issue will change to the status DELETED.

Image nr. 74 – Window Delete.

In addition, it has no menu option enabled, so that it can no longer get out of this status.

In JIRA-CLIENT the issue will change to the Deleted status and no operational action can be performed. (Image nr. 75).

Image nr. 75 – Transition to Deleted in JIRA-CLIENT.

In the Feature Request and Big Feature Request issues, the Re-Estimate status will be available in the following transitions: Continue and Send to Approve.


4 Practical case of a Feature Request This section explains the process of creating a Feature Request from the client, how to edit it after its creation, and the issue and its evolution by the support and monitoring team from the client.

Since most of the procedures like the creation and completion of the fields associated with the issue or the editing of these fields are common, links will be used to review certain points already dealt with in this document.

Creating a Feature Request by the client 4.1

See section: 3 Practical case of a Corrective Maintenance Issue in this document, to review the fields that make up the creation of an issue.

After clicking on the Create button, the Project and Type of Issue fields must be filled in. In this case, select Feature Request. (Image nr. 76).

Image nr. 76 – Create an Issue of Feature Request type.

Then, the fields and tabs of the issue will be completed (see Image nr. 7 - Window Create Issue)

As they are very similar, we recommend reviewing section 3.1 Creating a Corrective Maintenance Issue by the Client.

Once the issue has been created, the work cycle will start, as detailed in the following section.

Parameters and Windows of a Feature Request 4.2

To review the parameters and windows of an issue, see section: 3.2 Parameters and windows of the Issues of Jira User Manual.


Progress of the issue performed by the support team and 4.3monitoring by the client

Indra Support team is in charge of managing the issues created automatically in JIRA-MInd starting from the creation of Issues from JIRA-CLIENT.

The person responsible for the Component receives an email notification for each new created issue. (Image nr. 77 – Notification via email).

Image nr. 77 – Notification via email.

Other users of the Project can also detect the creation of the new issue in the section: Activity Flow of the JIRA Project. See section: Parameters and windows of the Issues of Jira User Manual section: Activity. (Image nr. 78).

Image nr. 78 – Activity flow.

The person responsible for the component selected in JIRA-CLIENT can assign the issue to a user, who will be the new person responsible for its management and monitoring. For this, press the button Assign in the issue menu. (Image nr. 79).


Image nr. 79 – Assign from the upper menu of the issue.

A Comment can be included in the issue. The user will receive it by email with the notification informing that the issue has been assigned to him/her. (Image nr. 80).

Image nr. 80 – Add comment when assigning the issue.

After assigning the Issue, it can be verified in the section People (Image) of the issue window that the name of the new responsible user will be present in the field Assignee. (Image nr. 81).

Image nr. 81 - Assignee.

In case the user accessing JIRA-CLIENT is the one who has to take charge of the issue, the button Assign to Me in the Assign option of the menu can be used in order to self-assigning the issue. (Image nr. 82).


Image nr. 82 – Self-assigned.

The management of the issue will be done as any other Service issue that is, following the workflow and advancing through the issue resolution process.

From the New status of the issue, the transition Analyse (Image nr. 83) indicates (from JIRA-MInd) the beginning of the Preliminary Study. From JIRA-MInd, it will be possible to add a comment related to the transition.

Image nr. 83 - Transition Analyze

After the previous step in JIRA-MInd, the client will see in JIRA-CLIENT that the associated issue has changed to the Preliminary Study status. Additionally, the user of JIRA-CLIENT assigned to the issue, and the reporter will receive an email notifying the status change to Preliminary Study. (Image nr. 84).

Image nr. 84 – Change to Preliminary Study in JIRA-CLIENT


This status change can also be seen in the section Activity of the issue in JIRA-CLIENT.

Image nr. 85 – View of the status change in the activity section.

In JIRA-CLIENT, just as they can receive a comment included in the issue, the user responsible for the issue will also be able to add a comment to the issue by clicking on the Comment button.

Image nr. 86 – Button to add a comment.

After the analysis of the work to be performed from JIRA-MInd, the issues will be estimated and planned. Therefore, the following fields will have to be modified: Sold units or Sold hours, as well as the following required dates:

Due Delivery: Delivery commitment.

Planned Start: Start date of the issues.

Planned End Date: End date.

After the Planning Estimation the support team will run the transition to Planning.

In JIRA-CLIENT, it can be verified that the Issue has changed to the equivalent status ESTIMATED/PLANNED. (Image nr. 87).

Image nr. 87 – Change to Estimated/Planned in JIRA-CLIENT.


In JIRA-Client, the assignee of the Issue can Approve the Estimation or Reject the Issue.

If we want to reject the issue from JIRA-Client, pressing the option: Reject Issue in the upper menu of the issue (Image nr. 88) it will change to status CLOSED. (Image nr. 89).

Image nr. 88 – Reject Issue.

When changed to the status CLOSED the issue will have finished its work cycle.

Image nr. 89 – Issue Rejected from JIRA_Client. Status CLOSED.

In JIRA-MInd, the Issue will be displayed in status CLOSED and the option Delete will be enabled in the issue menu.

If we want to approve the Estimation/Plan from JIRA-CLIENT, if we press the option: Approve Estimation in the upper menu of the issue (Image nr. 84) it will change to status APPROVED ESTIMATION/PLAN. (Image nr. 90).

Image nr. 90 – Approve Estimation.


Image nr. 91 – JIRA-CLIENT. Status APPROVED ESTIMATION/PLAN.

The equivalent in JIRA-MInd will be the status: APPROVED PLAN.

Once the planning has been approved, when the support team is available to start the work associated with the issue, the transition Work in progress will be executed (Image nr. 92).

Image nr. 92 - Transition Work in progress.

In JIRA-CLIENT, it can be verified that the issue has changed to the status: WORK IN PROGRESS, which informs that the work in the solution is in progress (from JIRA-MInd). (Image nr. 93).

Image nr. 93 - Status change to Work in Progress in JIRA-CLIENT.

When Indra support team (JIRA-MInd) finishes the development of the solution, they will perform the transition Test to show that the test phase starts.

The transition Test changes the status of the JIRA-Mind issue to Testing. However, in JIRA-CLIENT the status will not change, as this is a work of the MInd support team.

Once the test phase (Testing) has successfully finished, the support team (in JIRA-MInd) runs the transition Deliver. (Image nr. 94) .


Image nr. 94 - Transition Deliver.

In JIRA-MInd the transition Deliver leads to the status Delivered. (Image nr. 95).

Image nr. 95 - Status change to Delivered in JIRA-MInd.

The equivalent in JIRA-Client will be the change to the status DELIVERED. (Image nr. 96).

Image nr. 96 - Status change for Delivered in JIRA-CLIENT.

This way, the client will be aware that the work is fully completed. Then, the work performed from the Client side will be evaluated to accept them through the transition Approve (Image nr. 97).

Image nr. 97 - Transition Approve in JIRA-CLIENT.


If after approving the work, problems in the operation of other types of problems are evaluated, from JIRA-Client it is possible to reject the issue from the option Reject in the upper menu (Image nr. 98).

Image nr. 98 - Transition Reject in JIRA-CLIENT.

The rejection of the issue results in the reopening of the issue where the Reason for the Reopening and a Comment of the Reopening must be indicated. (Image nr. 99).

Image nr. 99 – Comment Reopening after Rejecting an issue from JIRA-CLIENT.

If it has been verified from the client that there is no more work to be done with respect to the issue, and it has been verified that all the work to be done has been completed, the Close issue option shall be selected and a resolution type from the Resolution drop-down menu will be chosen. (Image nr. 100).

Image nr. 100 - Resolution type

The End Date will be automatically recorded and a closing comment will be added.


5 Epic type issues in JIRA-CLIENT To create an Epic from the JIRA-CLIENT the following steps must be carried out:

a) First, access the Agile option in the upper menu of JIRA-CLIENT and then select the Board where we want to create the Epic.

b) Within the Board, click on the tab: Backlog. If the Epic board is not visible on the left side of the screen, select in the Tools side menu the option: EPICS.

Place the mouse anywhere on the Epics board and click on the (popup) option: Create epic.

c) The following mandatory data must be filled in in the popup window:

Name: Name of the Epic. Summary: Short description of the Epic. Description: Detailed description of the Epic. Component/s: Component selection.

d) If you want to change the name of the Epic, place the cursor on the Epic of your choice,

click on the drop-down menu ( ) and select one of the following edit options: Color: It allows selecting the Color for the epic. It will also determine the color of the

Epic link included in the issue associated with the epic. Edit name: It allows changing the epic name. View in JIRA: It opens a new browser window to display the epic in JIRA-CLIENT.

If we open the issue in the JIRA-CLIENT, by means of the ID of the field: External issue ID we will be able to query the associated Epic that has been generated in the JIRA-MInd. From the Board of JIRA-MInd, it will be possible to follow the evolution of this Epic, and to estimate (Image nr. 101 - Estimate from the Epic) directly the work to be carried out in the issue/s. The total of the estimate will be updated as the Issues of the epic are estimated.

Image nr. 101 – Estimation from the Epic

Mark as ready: It marks the Epic as finished. It can be reopened if necessary (See

section: Reopen an Epic in this guide). (Image nr. 102 – Mark Epic as finished).


Image nr. 102 – Mark Epic as finished.

The option: Mark as ready…

will check if the epic still contains any unsolved issue. A system message will warn us if this is the case. For further information, please, see section: Complete.

In case of confirming: Mark as ready, the epic will not reappear in the epic panel, although it can be seen in the report: Epic report.


Add Issues to an Epic 5.1

The following steps must be followed:

1 After creating and configuring the Epic in the JIRA CLIENT, we will add below the Issues that the milestone will include.

2 From the Agile menu in the JIRA CLIENT, select the desired Scrum board and click on the Backlog area.

3 If we don't see the Epic we want to work with, we will open EPICS from the left side toolbar.

4 From the Backlog select and click on the desired issue. Without releasing the button, (Image nr. 103 - Add issue to an epic) drag the issue to the field Issues within the epic. We will repeat this step as many times as Issues are included in the epic.

Image nr. 103 – Add issue to an epic.

The issue included in the epic will show the Tag with the color and name of the Epic to which it belongs and which will serve as a link to that Epic as. (Image nr. 104 - Add issue to an epic)

Image nr. 104 –Epic.Tag

Remove Issues from an Epic 5.2

If necessary, we can remove the Issues we don’t want to keep in the Epic, as follows:

1. Access the Agile option in the upper menu of JIRA-CLIENT and select the Board to locate the Epic containing the issue/s we want to delete.

2. Click on the Backlog or active Sprints and act in one of these two ways: 3. From the Backlog, select the issue we want to remove from the epic and without releasing

the button, drag the issue to the section: Issues without epics located at the bottom of the Agile board. (Image nr. 104 and 105- Remove issues from an epic).


Image nr. 104 – Remove issues from an Epic.

Or, from the Backlog or active sprints, click on the desired issue to display it on the right side of the screen and then click on the cross (x) to the right of the epic name and delete it (see next image).

Image nr. 105 – Remove issues from an Epic.

Complete and reopen an Epic 5.3

Below we explain how to mark as ready an Epic that we consider completed, and how to reopen it.

Complete an Epic

1. From the Agile menu in the JIRA CLIENT, select the desired Scrum board and click on the Backlog area.

2. If we don't see the Epic we want to work with, we will open EPICS from the left side toolbar.

3. Place the cursor on the desired Epic and press on the dropdown menu ( ) and then select the option: Mark as Ready (Image nr. 106 – Complete an epic). This action will change the


status of the epic to "Done", but it will affect neither the workflow of the epic or its status field nor the rest of Issues of the epic.

Image nr. 106 – Complete an epic.

Reopen an Epic 5.4

To reopen an Epic, it is necessary to have the appropriate permissions to edit Issues within the project to which the Epic belongs or to have global administrator permissions.

The steps to reopen an Epic are the following:

1. Find the Epic in JIRA-CLIENT in the Project where it was created, for example, searching by ID.

2. Then, edit the Epic to restore the field Epic Status to "To Do" or "In Progress". After saving the changes, the Epic will reappear in the Agile board.


6 Appendix 1

standard jira client - slsvn.indra.es · standard jira client use guide – practical case 5 1...

Documents