I'm new to JIRA and unfortunately I'm a bit confused :-( It would really appreciate if somebody could clarify the concepts used in JIRA. I read several tutorials, but they are all centered around software projects. In my particular case, I want to use JIRA for other purposes.
As a first step, I want my organisation to use JIRA for account management:
a) Employees join the organisation. --> add groupware account, add to user groups, install pc.
b) They may be inactive (e.g. sabbatical) --> change permissions.
c) They may marry (and change their last names) --> change e-mail, user id
d) They may move within the organisation --> change permissions
e) They may leave the organisation --> remove groupware account, etc.
In each step, different persons are responsible for these tasks, e.g.:
1) Help Desk leader creates the task
2) Someone from the groupware team adds the account.
3) ...when finished, the issue should be automatically delegated to the permission manager in order to create permissions, etc.
4) when everything is done, the issue goes back to the help desk leader and he will close it.
First question: Should I use a project "Account Management" for this purpose? Or would this be a bad idea? What would you do?
Second question: What are a) - e)? Issue types? Workflows? Workflow schemes? None of them?
Third question: What are 1) - 4) in JIRA terminology? Steps within a workflow?
I think that JIRA may help our company a lot. However, it seems to be crucial to fully understand the basic concepts and how they play together. Unfortunately, this is all a bit confusing at first (especially, if you use it in a language that differs from the one used in all tutorials...).
Any help is greatly appreciated!
1. Yes, that sounds like a very good mapping for it. You have a project for containing large numbers of requests
2. I think you've got a bit of a decision to make here. I can see two approaches
The more obvious one is to have an issue type for each of a-e. They would represent requests in the real world, so you'd get "new user", "dormant user", etc, requests, deal with them and close them. The problem with this approach is you could end up with stacks of issues building up against one user and it could become a pain to find them
The less obvious one is to have a single issue type of "user" and build a workflow for a-e. That way, each ssue would be a user, and a-e become things you do to that user
3. Depends on the answer to 2 - for the first answer, they are very definitely workflow transitions. For the second answer, where each issue is a person, they are still transitions, but with some complexity (As you'll need more of them)
Thank you very much! Good to hear that I'm not totally wrong...
Your two suggestions for 2) sound interesting. Especially the one with the complex workflow. If I understand correctly that would essentially mean "One and only one ticket per user". Create the ticket, if the user is supposed to be created. Close it, if done. Re-open it, if the user marrys, moves or leaves the company.
However, I want to have a form-based help desk, in which the users more or less create tickets by themselves and I think that the approach above would not work well. I can imagine that it is easier to create a new ticket/issue via help desk instead of re-opening the right one. Also the approach "one ticket for each transaction (create/move/marry/leave)" is better suited for creating reports such as "how many users moved in 2013".
Questions: Did I understand this correctly? Is the help desk approach feasible at all?
You've got the right idea from what I wrote, yes.
However, I did not made it clear that I wasn't actually recommending either approach over the other (yet). That's where we start to move on to how you'd like to use it, and, more importantly, what reports you want out. I wouldn't recommend one over the other without more questions. Which you just answered!
Your helpdesk description would make me lean towards the first approach. Combined with the report you just defined though, you defintely should be working through "5 issue types, based on request type". You can have different workflows for each type of request, different fields and quite a lot else. Most importantly, you'll find "show me all the issues opened in period X by their issue type" is an absolute doddle. You'll be able to allow people with basic Jira accounts use it to request more/changed access.
So there would be a 1-to-1 relation between issue types and workflows?
- issue type "New user" --> Workflow "New user workflow"
- issue type "Move user" --> workflow "Move user workflow"
Or would the issue type be a more generic "User account issue" with sub tasks? I'm asking because in case of a 1-to-1 relation, I could end up with a plethora of issue types and corresponding workflows. Probably, I haven't really understood the difference between issue types and workflows yet..?
Yes. Well, you could have a 1:1 relationship, but as you work out your processes, you might find enough similarities that you can use the same flows. For example, new user = new user flow, but remove user and inactivity = remove/inactivate user flow, and change name/change role = change user settings flow. In that example, I've got 5 issue types but only three workflows.
Sub-tasks are potentially a way to implement a mix of both of my suggested schemes - I didn't launch into them at first because it was worth exploring both separately first.
With subtasks, you can get really quite clever. Given what you've told us so far, I would be strongly tempted to set up soemthing like this:
Workflow for user with four status
So, a new user would have an issue created, capturing name, email, organisation etc, your team would move it to "active" once they've added the account, push it to "inactive" if the user has a sabbatical/parental leave etc, and move it to "deleted" if they leave permanently.
Worflow for subtasks would be a simple development style workflow with something like New, In progress, Resolved, Closed type status (Resolved = "request is complete", closed = "user sign off that they're happy")
In other words, you'd have one issue per user, with the status reflecting their current position. Then changes to that user would be requested as sub-tasks. When your team complete the subtasks, they would update the user status and other detail fields on the parent User-issue.
This is pretty close to something I've done for a client a while ago. We got even more clever than this with it too - the permissions change was hooked up to actually change other application settings automatically (on approval), moving a user to "inactive" or "Left" shut down their accounts in certain systems and so-on
Well, the service desk sits in front of your Jira data, presenting a simplified interface for the users. However, I've not used it enough to know if you could persuade it to fit perfectly with a "User = issue, Changes to user = sub-task" model.
In the worst case, I could imagine you having to triage things coming in from the service desk - "new user" would be fine, but "change to existing user" might have to be moved to be a sub-task once you've worked out which user it is.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Every time you release software, there's a bit of risk – that there's a bug, that something breaks, or that the feature doesn't resonate with customers. Feature flagging helps make high stakes s...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG