JIRA 5.x, first steps

JIRA 5.x, first steps Table of Contents: 1.) Change History:... 2 2.) URL:... 3 3.) Login:... 3 4.) Setting user profile:... 3 5.) Using filters:... 4 a) Changing existing filters... 5 6.) Configuring your dashboard:... 5 a) Choose another already existing dashboard... 5 b) Create / change your own dashboard... 5 7.) Creating a JIRA entry... 6 a) Projects... 7 b) Issue types... 7 c) Issue fields... 7 - Summary... 7 - Story Points... 7 - Priority... 7 - Due Date... 7 - Desired Delivery Date... 7 - Description... 8 - Components... 8 - Assignee... 8 - Config... 8 - Inquiry by... 8 - Affects Version/s... 8 - To be informed after creation... 8 - To be informed later / To be informed later 2... 8 - Build No.... 8 - Fix Version/s... 8 - Steps to reproduce... 8 - Epic / Theme... 9 - Flagged... 9 - Attachment... 9 - Publication Range... 10 tallard JIRA first steps (2).docx 1/20

d) Notification... 10 8.) Versioning (for developers only)... 10 a) Version number... 10 b) Build number... 10 9.) Agile Workflow (for developers only)... 11 a) Agile boards... 11 - Product Backlog / Priority of work (Scrum view):... 11 - Work view (without swimlanes):... 11 - Work view (with swimlanes):... 12 b) Workflow structure... 12 - Scrum workflow... 12 c) Workflow actions... 15 - Description of classic view:... 15 - Transitions and Actions (classic view):... 15 - Priority of work (classic view):... 15 - Priority of work (agile boards):... 16 - Transitions and Actions (agile board):... 16 - Creation of own agile boards:... 16 1.) Change History: o Version 2.5; May 08, 2013. Changes: o o o o o Paragraph 2.) URL: Change the URL address Paragraph 4.) Setting user profile: Minor rework on how to change your profile in the beginning Paragraph 7.) b)setting user profile: Issue types: Minor rework on Issue types. Added Story and Epic to the description. Paragraph 7.) c) Issue fields: Minor rework on fields Flagged, Assignee and Inquiry by. Added field Story Points. Renewed pictures for field Epic / Theme. Paragraph 7.) 7.d) Notification: Moved from 9.) c) Workflow actions a) Paragraph 9.) a) Agile boards - Product Backlog / Priority of work (Scrum view): The priority of work is described by the positioning in the actual Scrum board. After an issue is moved from Backlog to an actual Sprint the product owner prioritizes the issues. The issue at top has the highest priority. tallard JIRA first steps (2).docx 2/20

In the Scrum Plan board you change the priority of an issue by click-and-hold the item with the mouse and move them to a higher position. In the Scrum workflow a developer always chooses the highest positioned issue and works on it. - Work view (without swimlanes): The image above displays a possible view of the Scrum board in Work mode (without so called swimlanes ). This view offers a maximum of overview. - Work view (with swimlanes): tallard JIRA first steps (2).docx 3/20

In another possible view (see picture above) swimlanes are activated. You see all issues in order of their priority and existing sub-tasks strictly assigned to the main issue. With this visualization all developers see which issue has the highest priority (that is not always clear in the view without swimlanes!) and which sub-tasks of a story belong to one issue. o o Workflow structure: Major rework on Workflow structure. Changed the structure from the classic workflows to Scrum workflow. New description and new picture added for Scrum workflow. Paragraph 9.) d) Workflow actions: Major rework on Workflow actions. Added description of classic view, priority of work and transitions & actions for classic and Scrum view. 2.) URL: - JIRA: https://jira.autoonline.com - Official JIRA manual: https://confluence.atlassian.com/display/jira/jira+user%27s+guide - Official Greenhopper manual (agile development plugin for JIRA): https://confluence.atlassian.com/display/gh/greenhopper+user%27s+guide 3.) Login: Use Windows Login data for login. Please contact AO Technics in case you still encounter problems. 4.) Setting user profile: Go to your login name displayed on the above right corner, click on the sign to the right of it and then on Profile : There you may want to change your preferences (like language change) by clicking on the Edit pencil: tallard JIRA first steps (2).docx 4/20

Please change your Avatar with a fitting profile picture (this is important especially for developers). Optionally also change language. It is strongly adviced to change preferences as displayed below (unless you want to receive plenty of e-mails): 5.) Using filters: You probably don t want to use only the see all issues filter which is active at start. tallard JIRA first steps (2).docx 5/20

It s highly recommended to create and save your own individual filters and you can even share them. At first, click on the issues (German: Vorgänge ) field (not the sign beside it): Your left frame should look like the picture above. If not, just click on the New Tab below and then, if the frame still doesn t look like above, click on Switch to simple search. Now you can select all those fields you want to filter for and click on Search button. If you like that filter, you should save it by clicking on Save. a) Changing existing filters Unfortunately, Filter handling in JIRA is not very user-friendly. You can do it as followed: o click on the issues field (not on ) o click on Edit tab above o change your filter as desired o Click on button Search o Click on Summary tab o Click on Save as or Save tallard JIRA first steps (2).docx 6/20

6.) Configuring your dashboard: There are two ways to set up your dashboard: Choose and load an already existing dashboard (which is strongly recommended for foreign users) or create your own one. a) Choose another already existing dashboard o Just click above left on the sign beside of Dashboards and then on Manage Dashboards. o Click on the left on Search o For foreign users: Type in your country name (e.g. Spain ) o Select your dashboard. b) Create / change your own dashboard Your dashboard is your JIRA start screen and you are invited to reconfigure it as your wishes. Just click above left on Dashboards (not the sign beside it), then to the right on Tools and finally on Create Dashboard : Enter a name for your dashboard and click on Add. Afterwards click above right on Add Gadget : There are plenty of (more or less) useful gadgets here. But one of them is highly recommended to install: the gadget Column order. Choose it and click on Add it now. If you have finished all your gadgets click above right on Finished. You now need to configure your Filter results gadget. Select under Saved Filter one of those filters you have saved before (see point 5.) and click finally on Save. Your gadget could look similar to the image below. If you want to edit your gadget again, you need to click on the gadget s above right corner on the sign and then on Edit : tallard JIRA first steps (2).docx 7/20

7.) Creating a JIRA entry A JIRA entry is called issue (German: Vorgang ). Just click on the above right corner to create one: a) Projects If you don t know which project is relevant, just choose project AO_Inbox. Issue will then be assigned to the relevant project later on. b) Issue types Some remarks regarding issue types (in case of doubts use Task (No QA! ): - Issue type Task (No QA!) is only for issues that don t require any programming (related to the project). Caution: Task (No QA!) issues will never be tested by QA! Choose another issue type if QA tests are required. - Issue type Bug means; there is a program error (bug) to be fixed. - Issue type Change Request means: Program should be changed in another way than just Bugfixing (e.g. features, configurations etc.) - Issue type Story is for agile boards only (e.g. Scrum); Story is a description of a feature that needs to be created or changed. - Issue type Epic is for agile boards only; Epic describes a group of related stories. c) Issue fields Main Fields: tallard JIRA first steps (2).docx 8/20

- Summary Summary can be either in English or German. Of course, if non-german speakers will be involved, everything should be in English. - Story Points Abstract measurement of complexity and size of a requirement. - Priority Self-explaining. Please also refer to Paragraph -d), Workflow actions. - Due Date Self-explaining. - Desired Delivery Date Self-explaining. - Description Describe your issue in details here. You may also enter another issue key here (e.g. AGNT- 23 ) which would result in a link to issue 23 of the AO_Agents project. - Components This field only appears in certain projects. It helps to specify which part of project is meant. In the above mentioned projects, the component selection is mandatory. In case you need to enter a new component, you need to create one first: o Click on Administration tab (see above, not the sign beside it) o Select the respective project o Under Components click on Add a new component - Assignee It s mandatory to enter a person here. If you don t know who it is, select Automatic here. - Config Enter yes, if issue contains a change request or bug that can be fixed only by a configuration change. It means that no new build is necessary. - Inquiry by This field only appear in certain projects. Select a country the issue either originally came from or is destined for. - Affects Version/s This field only appears in certain projects. In case the appropriate version is not listed there, you need to create an own one first: o Click on Administration tab (see above, not the sign beside it) o Select the respective project o Under Versions click on Show all or Add a version o Enter Version Name, Description and Release Date (if you know it) and click on Add Please refer also to 8.)) Versioning for rules and naming of versions and builds. - To be informed after creation Enter a JIRA user who will be informed automatically after issue is created. Note: It is not possible just to enter an email address; user must be exist in JIRA first. - To be informed later / To be informed later 2 Enter a JIRA user who will be informed automatically after issue had been closed. Note: It is not possible just to enter an email address; user must be exist in JIRA first. - Build No. This field only appears in a few projects. tallard JIRA first steps (2).docx 9/20

Please refer also to 8.)) Versioning for rules and naming of versions and builds. - Fix Version/s This field only appears in certain projects. In case the appropriate version is not listed there, you need to create an own one first: o Click on Administration tab (see above, not the sign beside it) o Select the respective project o Under Versions click on Show all or Add a version o Enter Version Name, Description and Release Date (if you know it) and click on Add Please refer also to 8.)) Versioning for rules and naming of versions and builds. - Steps to reproduce Self-explaining. Especially relevant for issue type bug. Additional Fields: - Epic / Theme Epics are issues that are too big to finish within one sprint. You should collect many stories in one Epic issue. In this case, you should enter for each user story an existing Epic issue key here. After you ve created e.g. an Epic and two Stories take a look at the Plan Board. Click on one of the Stories On the left side you get an overview of the Epic: tallard JIRA first steps (2).docx 10/20

- Flagged You may enter if an issue is marked as Impediment. - Attachment You may enter files here. You will also be able to paste a screenshot in JIRA however not here but in a next step: You need to create this issue first. Then go More Actions and then to Attach Screenshot in order to paste screenshot from clipboard. - Publication Range Similar to Due Date, but with free text (e.g. End of summer ) d) Notification There are two ways of notifications: In case you want to be informed yourself of a certain other issue, you can put it on a watch list: o Click on an issue (by clicking on issues before [not the sign beside it] and then by clicking on the link in column Key or Summary ) o Click on Watch : You will now be informed by email about any changes on this issue. In case you want to have informed another user about an issue, just click on number in brackets to the right of Watch instead and you can select one out of a list. tallard JIRA first steps (2).docx 11/20

8.) Versioning (for developers only) Each program should display a full version number, containing program name, version number and build number, e.g. SPEEDonline 2011.02.01 Build 005 : a) Version number The AUTOonline syntax is as followed: YearOfRelease.VersionNumber (if there is no hotfix released yet) or YearOfRelease.VersionNumber.HotfixNumber (if there is at least one hotfix for that version). Examples: - Version 2011.02 means 2 nd regular release in year 2011. - Version 2011.01.02 means second hotfix for first regular release in 2011. b) Build number The AUTOonline syntax is as followed: - Three-digit, with leading zeros, starts with 001. - Increases by one with each internal deployment. - However: After each new version number starts at 001 again! Examples: - Version 2011.02 has just been released with build number 004. - As soon as someone checks in code for version 2011.03, build number falls down to 001 again. - However, if a hotfix 2011.02.01 has to be built, you have to check in for Build 005. tallard JIRA first steps (2).docx 12/20

9.) Agile Workflow (for developers only) b) Agile boards - Product Backlog / Priority of work (Scrum view): The priority of work is described by the positioning in the actual Scrum board. After an issue is moved from Backlog to an actual Sprint the product owner prioritizes the issues. The issue at top has the highest priority. In the Scrum Plan board you change the priority of an issue by click-and-hold the item with the mouse and move them to a higher position. In the Scrum workflow a developer always chooses the highest positioned issue and works on it. - Work view (without swimlanes): The image above displays a possible view of the Scrum board in Work mode (without so called swimlanes ). This view offers a maximum of overview. tallard JIRA first steps (2).docx 13/20

- Work view (with swimlanes): In another possible view (see picture above) swimlanes are activated. You see all issues in order of their priority and existing sub-tasks strictly assigned to the main issue. With this visualization all developers see which issue has the highest priority (that is not always clear in the view without swimlanes!) and which sub-tasks of a story belong to one issue. c) Workflow structure - Scrum workflow Summary: A new development request will be either moved from a JIRA start project (for AUTOonline: AO_Inbox ) to a Scrum project or directly created into a Scrum project. The product owner of Scrum prioritizes issues in the backlog of the Scrum Board (see 9.) d) Product Backlog / Priority of work (Scrum view): The priority of work is described by the positioning in the actual Scrum board. After an issue is moved from Backlog to an actual Sprint the product owner prioritizes the issues. The issue at top has the highest priority. In the Scrum Plan board you change the priority of an issue by click-and-hold the item with the mouse and move them to a higher position. In the Scrum workflow a developer always chooses the highest positioned issue and works on it. tallard JIRA first steps (2).docx 14/20

Work view (without swimlanes): for more details); issues with highest priority stand on upmost position. Signification of statuses: o Open (visible in column To Do ): Starting status for all new issues, usually assigned to product owner. If a developer moves an issue from Column To Do to In Work, status changes also to In Work. This indicates developer starts working on it. Developer becomes assignee automatically after status transition. o In Work (visible in column In Work ): Indicates that a developer works on that issue. Usually issues are called (user) stories and are typically divided into many sub-tasks (see 7.) b), Issue types for more information). Once developer has fixed a sub-task he moves it to column To Review and it becomes also status To Review. But if a developer moves a whole story from column In Work to To Review, status changes from In Work to Ready for QA. The different status names thus show that different actions have to follow: while single sub-tasks will be code-reviewed by another developer, stories need to be tested according to their requirements. o Ready for QA / To Review (visible in column To Review ): There are two different actions that could take place in column To Review : If a subtask has status To Review another developer has to code-review the issue. If a whole story has status Ready for QA a member of QA has to test the issue according the requirements. o In Test / In Review (visible in column In Test ): The code-review or the tests are executed in column In Test. After approval, stories will be moved to Done column; you have to choose between status Ready for Deployment or Closed. Sub-tasks will be moved to Done column, with status Closed. Please be aware: If you set an issue to Closed status without having deployed version first, a notification e-mail will be sent to the reporter of that issue. If that reporter do not belong to your company that would lead to irritation as they might think version would already have been published. o Ready for Deployment (visible in column Done ): This status only indicates that tests have been done, but deployment not yet. o Closed (visible in column Done ): Final status if issue has been realized (or cancelled). tallard JIRA first steps (2).docx 15/20

tallard JIRA first steps (2).docx 16/20

d) Workflow actions - Description of classic view: In JIRA, the most common view is Scrum view. But behind the visualization of Scrum all issues exists another view which we call classic view in this documentation. The classic view of an issue appears if you click on an issue in a Scrum board. It also may be a tool to change transitions and get an undetailed information on the priority of an issue. A user should normally use Scrum view but working with classic view is described as follows. - Transitions and Actions (classic view): Once you have selected a single issue (by clicking on issues before [not the sign beside it] and then by clicking on the link in column Key or Summary ), you will see a screen similar to this: Project / Project key Summary Causes no status change! Causes status change ( transition )! It is important to understand that you can perform a lot of actions in JIRA once you have selected a single issue. But only the right red-framed action group will cause a status change according to the workflow (usually Scrum workflow). You can see two Assign buttons on the example picture above, but the left one only changes the assignee and nothing else. The right button also changes the status from Open to In work. In JIRA only two transitions (actions with status change) will be displayed. If there are more you will find them by clicking on Workflow. - Priority of work (classic view): Two fields describe the priority of work: tallard JIRA first steps (2).docx 17/20

o Rank Field o Global Rank Note: There is still another priority field (just called priority or, shorter, only P ) which, however, AUTOonline doesn t use anymore as it only differs between Major, Minor etc. and does not make any difference between issues with the same e.g. high priority. A low ranking means this issue is more important than others. - Priority of work (agile boards): If you use agile Boards, issues with highest priority are displayed on top. - Transitions and Actions (agile board): Transition changes (from one status/column to another) are executed by click-and-hold an issue and drop it on a different column. Afterwards, issue is automatically assigned to you and for some transitions a window opens to insert further information. - Creation of own agile boards: Everyone is able to create his own scrum board. You only have to click on the sign beside Tools and click on Create board : There are two options: Kanban and Scrum. The main difference between these two board is that Kanban has no Sprints. A Kanban board is useful if you usually work without project due date rather than just a continuous work. Therefore it s recommended for e.g. support departments. After creation, you should configure your new board by clicking on the sign beside Tools and click on Create board : tallard JIRA first steps (2).docx 18/20

Here you have different options. You may change or edit your filter, add new columns or quick filters, etc. In this document the most common settings are described. You may set up your Scrum board as your wishes. For more information, please refer to official Greenhopper manual (agile development plugin for JIRA): https://confluence.atlassian.com/display/gh/greenhopper+user%27s+guide In tab Columns we map the JIRA statuses (according to the picture below) to each column and (optionally) change Column Constraint to Issue Count, excluding sub-tasks : tallard JIRA first steps (2).docx 19/20

In tab Quick filters you are able to add (sub-)filters that display in the upper menu bar of the Scrum board in Work mode. You may create own quickfilters by using the JQL language. The preset filters are: In tab Estimation the view for the Burndown chart is determined. Options are None (only Story Points are shown) and Remaining Estimate and Time Spent. tallard JIRA first steps (2).docx 20/20