1. Oslo and Bergen can easily see what the others are working on
2. Better traceabilty of code changes (an issue can contain a reference to a code change)
3. Better work planning
4. Better communication between developers
5. Help us work as a team, not just a collection of individuals.

1. Log in to JIRA (scrum.met.no) using the same user-name and password that you use for svn access (This is the LDAP password at met.no, external users have an external LDAP password).
2. Verify that you can go to “manage dashboards” and search for dashboards created by Alf Grini. You should find the NorESM default dashboard.
3. Add the NorESM default dashboard as a favourite.
4. The dashboards shows the epics (large tasks we are supposed to solve for the next version) together with some other information. It the NorESM “homepage” at JIRA.
5. Make sure you can go to agile =⇒ manage boards and find the NorESM scrum board. This board is shared between Oslo and Bergen, and it is our way of communicating what we are working with right now.
6. Note that the scrum board can be filtered by components, so it is easy to look at only MICOM issues or only cam-oslo issues.

1. Go to “create issue”. Note that in NorESM, the issues are different components. Make sure you select the right component for your issue.
2. Also add other information to the issue as label (can be e.g. be a project-name). Adding Multiple labels is OK.

An issue can be created as one of several types. In NorESM we will use the following definitions:

1. EPIC: A task which demands some man-months. For example in the EVA-project, a task is an epic. An epic consists of several stories. See https://confluence.atlassian.com/display/AGILE/Adding+an+Issue+to+an+Epic
2. STORY: A task which demands a couple of man-weeks. Typically the sub-tasks in EVA are stories.
3. TASK: A story will have several sub-tasks. They are created inside the story (open the issue =⇒ more =⇒ create sub-task). The tasks will last some man-days and it is the tasks which will be added to the sprints.

Take the example of the EVA project proposal: “Task 2.1 Ocean dynamical core development” is an epic. It consists of several stories. One story is “2.1.2: Introduce a hybrid layered framework to facilitate higher vertical resolution in the surface boundary layer”. This story should be splitted into several work-tasks. Each of the tasks should be approx 1-2 man-days. Examples of tasks can be “make program compile with gfortran”, “create 1d test-program” etc. Those tasks should be added the the appropriate sprint.

1. Blocker: We need to solve this immediately. Some project can not be delivered because of this problem. Problem blocks other people from working.
2. Critical: Should be solved as quickly as possible. Major problem with product functionality.
3. Major: This is the default priority
4. Minor: Nice to do this, but not really necessary
5. Trivial: Fix this when you have the time
6. Not prioritized: We don't need to do this

1. Find out together with your team which issues are most important
2. Try to compose a sprint so that the product (NorESM) is more or less usable at the end of the sprint.
3. If a task requires more than 3 days of work, it should probably be splitted into sub-tasks. Create an story (or epic) and convert the issues into sub-tasks of the story. Go to issue, more actions and “convert to sub-task”.

1. Every other week, we will create a new “sprint”. That means that the scrum board will be refreshed. (see below)
2. When you want to start working on something you should always do something which is in the sprint. Those are the tasks that the team has defined as most important.
3. Go to the task and choose “assign” and “assign to me”.
4. Also in the task go to “more actions” and “start progress”. You can also just drag the task over in the “in progress” column in the scrum board
5. Drag the issue to the “resolved” column when the problem is solved.
6. You the board to see what your collegues are working on. Comment on their issues!

1. When the task is finished, there should always be a comment saying which changeset in the version control system which solved the problem. For example if I solve task “NE-10”, I should comment in JIRA “this task was solved by svn changeset nn”.
2. In svn, I should commit with a comment mentioning the issue, something like “svn commit -m “solved issue NE-10 by removing possible divide-by-zero””
3. In theory, JIRA can, given that the commit message is mentioning the issue, show code differences. This has not been set up (yet).