The way I've been approaching the distinctions of issue types is this - I'd LOVE some feedback or alternative suggestions to consider:
An example of these distinctions could be:
What do you all think?
I agree 100% with that approach. I use the same as a matter of fact :)
The use of tasks is key, because sometimes the PO is not aware of some workload that is required to achieve a goal (processes like refactoring, BD maintenance - schema changes, etc .. -, API versioning ... ) may not be directly linkable to a user story specifically, but they need to be present on the backlog.
How about considering those 'Sub Task' as 'Engineering Tasks', so there is no Sub Tasks at all, the logical hierarchy is as follows:
EPIC -> STORY -> TASKS
TASKS can be estimated (Story Point) and assigned to different teams, tasks can be tracked in burn-down reports.
Advantage in the above approach is technical component level Story Point estimation can be done and sum of Task level Story Points is total Story Points of the Story.
Tasks can be linked to Story.
What about the workflows that stories and subtasks follow? Do they use the same workflow?
For instance: Based on Mars example:
Story: User Login screen:
Most likely, subtasks (and tasks) will go through the workflow:
since they are development tasks (there could be more states). But the story itself doesn't need to go though this workflow. Perhaps the workflow stories will follow will be something simpler like:
The question is: how do we keep two flows in Jira. Do we have 2 different boards, one for stories and another for subtasks/tasks?
Over time, I have been used to do the same as Mars describe and it works perfectly
Epic: Generic or large matter to accomplish, but smaller than the project itself
Stories: Features viewable by the user. In fact , stories are often derive from the sprint epics, with the customer, during sprint planning. So they are in "user terms".
Tasks: Same thing as Story but more internal stuff, which does not correspond to demonstrable stuff
Sub-task: Steps to do within a task or story, necessary to complete them.
@Willy De la Cruz Sierra regarding workflow, you can have both statuses for subtasks and stories in one workflow (board) - just don't move stories into those statuses strictly for subtasks.
In your case, the board will look like this:
Stories move to InProgress and stay there while subtasks move through Coding, Reviewing, Testing, and Done. When all subtasks are Done, move the Story to Done.
In our team, we use to keep it simple:
InProgress encompasses coding, code review and anything else the devs need to do before it's ready for QA. For us, subtasks rarely move to QA Ready, typically they go directly to Done. When a Story goes to QA Ready, whatever testing subtasks waiting in ToDo start moving to InProgress and then to Done. Once all subtasks are Done, the Story moves to Done.
If you are looking for difference between these three
Epic is An epic captures a large body of work. It is essentially a large user story that can be broken down into a number of smaller stories. It may take several sprints to complete an epic.
When you say there's no difference between Story and Task I guess you mean that there's no technical difference in that they're both "issues" as far as JIRA is concerned. So they get shown the same way on a board, for example.
There definitely could be a semantic difference in that a Story could be about something of value to users, whereas a Task could be something of value to the team. The two are likely to have different workflows and different fields to reflect those purposes, depending on how the project has been configured.
The diagram in Bob's video is misleading as it suggests that Tasks sit beneath Story, which this is not the case in Jira. His video explains the generic concepts which is not specific to Jira. Theme does not exist in Jira, but some organisations use 'Initiatives' to represent that.
In Jira, Epics can be broken down into tasks and stories, which can in turn be broken down into sub-tasks.
It's not badly misleading - Tasks can sit beneath Story in Jira. It's about the configuration though. It would be better to think in layers. Epic is one layer, Story a second layer, and sub-tasks third.
But there can be many issue types in the Story and Sub-task layers. By default, Jira creates issue types called Story and Task in the "Story" layer, along with several others. And by default, "sub task" and "technical task" are added in the sub-task layer. But an admin can add, remove or rename them. Almost all of us mess with these schemes.
And, specifically, a lot of us rename "Task" to something else or remove it, then add a sub-task type called "Task". When an admin has done that, Bob's video is accurate. It's quite common to find a Jira system that has Epic -> Story -> Task.
As I'm reading this, I have a PM who's really confused, and she says she's always thought of "TASKS" as sub-level to "STORIES" - but I tried to explain that she is thinking of a "Sub-Task" - which also confuses her. Layers is a good thought, but JIRA documentation and culture don't talk about layers, so it's a new concept to explain, and you sort of always have to explain it.
Fix the name of a "Sub" anything to the same thing across the board - like "Sub-Issue", and then give it a "type". So JIRA would then have: Issue / Issuetype, Sub-Issue/Sub-Issuetype (where the "types" are customizable by Admins, and include the OOB standards - such as "bug, story, etc..."). By means of these consistent relationships, I think it would reduce confusion about "sub-tasks", "tasks" and cause better overall understanding of the relationships.
Enabling the story points field on the task issue type is possible (and one of the more uncomplicated tasks), but I don't think it's there in the most basic workflow scheme. I'd look at the "where is my field?" option in the admin dropdown, if it's there on your view. If not, then reach out to whoever's managing your instance (hopefully, a JIRA admin).
A board is a view that represents a body of work being worked on. It can show pretty much anything according to a filter, so if you want subtasks to show on it, you can make it so, or you can exclude them.
Hi @Brian Shanblatt
As stated by Chander, Please have a look at these:
Our team adds tasks as "technical tasks" that are large enough to be stories (bigger than a sub-task), but do not directly add value to the customer. Using a different issue type lets me create a customer focused dashboard for stakeholders and another one with all issues for the team.
Our team estimates the tasks, but we had a historic problem with our internal customers trying to hold the team to large story estimates made six months in advance. I have been thinking about adding a T-Shirt size field and using that for stories and keeping the points attached to actually work we know enough about to estimate. I know a lot of teams would say that the stories were simply not broken down enough to begin with, which is probably true. If we had more layers of Epics, like themes maybe, we wouldn't have to use stories in this way. In the end, anyway you can simplify the customer's view so their asks don't get lost in projects with thousands of issues, the better.
+1 on making it easy to see which backlog items deliver value to users!
I would avoid quoting estimates in person-hours for the very reason you found: stakeholders will hold you to them.
Story points are intended to be used on items for which you want to be able to estimate delivery times, which usually means those that deliver value to users or the business. By getting a measure on how many points a team can deliver per sprint, and putting points on the user stories, you can estimate how many sprints it will take to get everything you want to users.
The points are meaningless to anyone outside the team, but if you know the team's "velocity" (points-per-sprint) you can estimate by which sprint they'll deliver the stories required. That way you can give the customer a time-box, but of course priorities will change so you reserve the right to change which stories get done to get them what they need.
The idea of Scrum/Agile is to break down deliverables into small, incremental pieces that each give some value to users. By small I mean can be done in one sprint. If it’s not sprint-sized then it’s an Epic, and you need to think hard to break it down further into smaller pieces of value, tracked as Stories.
I recommend going on a Scrum training course. Kane Marr does an excellent one.
Agreed, stick to story points and avoid the agile trap of tasks, I would only use tasks if teams are offshore and you don't have transparency of teams and their work, or teams that like to go to the detail then let them use tasks...
But story points should be measured on stories and burn downs or burn ups should all be based on the progress of the story would be my suggestion.
Agile is a philosophy and as such is implemented with vary degrees of rigidity. I teach JIRA classes to many students who use Agile. To date I have not found 2 companies that use Agile in the same way.
JIRA is a software that attempts to facilitate the Agile philosophy. As such, JIRA provide a fairly broad approach to agile terms and functionality.
In general, Epic, Story & Task are all Issue Types in JIRA and therefore can be organized in any heirarchy the users wishes (via linking and advance workflow rules). For example, JIRA would even allow you to make an epic dependent on a task - though no one would likely ever want that.
Once you get to scrum boards (and also JIRA portfolio), Epics do have some unique functionalities that you do not have with any other Issue Type.
This is how we use Epics, Story & Task ..
Epics are used as functional classifications (verticals) of our product, it makes more sense if we need to do some kind of measurements... Epics in this case will live as long the project exists.
Story is a kind of work that directly or indirectly affects our end user experience.
Task is a kind of work that is pure technical, mostly NFRs, deployments, optimisation, code level, configs, etc ...
I think we must use these issue types to best suite our requirements ...
Hello @David Heller,
Epics are the vague, large clouds far back on the horizon. Once you get closer to them you will notice more and more details, usually sorted into Stories.
The stories are the actual items for getting things done, the epics are the grouping tool to keep an overview to allow hierarchical relationship.
Grouping, you could surely do via labels, but labels are just a bunch of strings, get mistyped, might be attached anywhere and cannot be classified. With epics, you can actually work with them and have them
To break down the work to implement a user story I use Technical Task sub-tasks under the Story issue if we want to assign them to different people, for example. This makes it easy to keep them in the context of the story and to see when they've been completed. Sub-tasks are similar to issues but always live under another issue.
For ambitious user stories that are too large to estimate reliably, I use an Epic issue and break it down in to separate Story issues that each deliver some value to users but are small enough to estimate reliably.
For work that needs to be done but is not releated to a user story, such as setting up build automation or upgrading a library, I use Task issues so we can easily see which backlog items are delivering value to users and which are for the team. A Task doesn't get story points, for example.
When you first install JIRA Software, the Story issue point has the Story Points field. This numeric field can be used as an estimation statistic on JIRA Software Boards, and if you're using a Scrum board then you can see Story Point info rolled up to the Epic. You'll also see it on various JIRA Software Reports.
You can modify the field context so the Story Points field is available on other issue types, and once you do that, there's really no difference between a Story and any other issue type. I like having different types of stories (so they can have different workflows), so under my epics I have issue types like Course Development and Video.
Velocity is supposed to tell you how many sprints it will take to deliver a set of user stories, so you can tell your users/customers when they'll get what they need. So I would only put points on Story issues, not Tasks.
If you put points on Tasks then the team's velocity does not reflect how many stories they can delivery per sprint, so you can't use it to estimate the number of sprints required to reach a delivery milestone.
It's important to show Tasks and other things that don't deliver value to users on the team's backlog, but they should reduce velocity not increase it. The team has to make a call as to how much of that "drag" they include in sprints.
That's a really weird way to look at it. Sprint points should be used to gauge an amount of assigned work per sprint, regardless of whether its delivering value internally or externally. Not assigning points to tasks seems to be breaking a fundamental feature of the process. If you want velocity on stories, then report on stories and not tasks, but failing to estimate tasks is throwing the baby out with the bath water.
It is a debatable point (groan, sorry) but the way I see it if you put points on all items, even those that don't deliver customer value, then how do you estimate when your backlog items with customer value are going to be delivered?
I'm assuming the team uses their velocity to tell the Product Owner when a set of customer backlog items will be delivered. So the velocity needs to be a measure of how much the team can deliver to customers per sprint. If you include internal team tasks in velocity then you've basically ruled out any future team tasks, because you're estimating delivery dates on the assumption that the team is only working on customer stories.
Bug fixes is another interesting case. I prefer not allocating points to bugs because your giving the team's velocity a boost. Why would you give a higher velocity for introducing more bugs? Bugs actually slow the team down, so having to fix a lot of bugs in a sprint should reduce their velocity, because they'll take longer to deliver the customer value in the backlog. Giving points to a story and then giving more points to the bugs that got into the story implementation seems like double counting.
So IMHO it comes down to how you are using velocity. If you are using it to estimate when customer stories get delivered then points should only be put on customer stories. If velocity just says how much work the team can do per sprint then delivery estimates will assume the team never works on team tasks or bug fixes, which seems bad.
Sure it's debatable, but I don't think you're not delivering customer value per-sprint just because it's not a feature that's immediately visible to them. Anything you do should be delivering value whether it's releasing a new feature, or improving job processing, or just resolving technical debt so developers can do their job faster (i.e. deliver more "customer-perceived value" faster) in the future.
Regarding velocity and bugs, on my instance we actually don't have an option to assign points to bugs, so there's no velocity boost or "reward" from adding bugs to a sprint.
Honestly, I think leaving points off of your backend tasks is probably hindering the reporting aspect of this hypothetical project. If "points on customer-facing items" is a facet you want to evaluate on your sprint, then perhaps you can look at story points delivered on stories, instead of story points delivered on stories and tasks combined. I think it all comes down to how you set it up, but my main point/opinion is that not counting units of work on backend tasks is, frankly, bad practice.
Adam, Mike, great debate on the topic.
We have got one item settled. No story points for bugs!
IMHO, the product owner has to understand all the work involved in the making of a product release. If he determines that 'direct customer value' appears minimal, than he can weigh it against technical debt, and occasionally influence decision making to even defer technical dept. Else, you end up with no one being interested in the long term technology evolution of the product and an overemphasis on delivering 'direct customer value'. Its a fine balance.
As a best practice, we tend to clearly state value of technical debt to explain why it has to be taken up now vs later. And we use technical leads as sprint owners, to ensure that sprint owners can effectively influence decision making, as well as have grasp to be able to understand the product owners business perspective, to take/understand the decisions.
Ultimately, finding the balance involves technical folks keeping a fair business perspective and the p.o. keeping a fair technical perspective. Somewhere between, lies the balance!
Velocity has to point to the net additional value the team is adding to the product (direct as well as indirect).
Yes, a very interesting conversation.
A couple of points
If you don't assign points to bugs, how do you know the proportion of your team's time goes into this activity? This knowledge can drive process improvements or the adoption of practices aimed at reducing the number of bugs or finding them early.
It's a similar thing with technical debt, how do you make decisions about the risk/value of dealing with technical debt unless you estimate and track it?
Finally, why would anyone think of dealing with bugs as a velocity 'boost' unless they had some perverse incentive to hit a certain number of points in a sprint? If you wanted to game the system you'd just estimate higher to make the numbers look better.
I would say that whoever created the bug should have to fix it, and they get awarded fewer points accomplished in a particular sprint because they dedicated at least a portion of their time to fixing it instead of enhancing some other feature. This would hopefully incentivize people to be more careful in their PRs, but unfortunately, would cause some grief when looking at the pre-sprint summary for each user. If they caused a bug, though, they should be putting in that extra time to fix it ;-)
Most Agile teams I've worked with will map their requirements as follows:
The intent behind this is, when requirements are first created, they are nebulus and Epic in size (i.e. they take longer than your Sprint/Iteration to complete. Once you begin to break this down into pieces that can fit within a Sprint, these requirements become Sprint-ready. To track and monitor progress within the Sprint itself, as well as to help with forecasting a team's capacity, you can break down these requirements into individual tasks or technical steps required to resolve them.
How this works in JIRA...
How this works in JIRA is, you create Epics first, then you break these epics into Stories which you link back to the Epic. When you're monitoring progress in your Sprint, you break down the Stories into Sub-tasks and track progress via these on a Scrum board. Of course, this is an optional approach, but one I've seen most Scrum teams undertake.
Remember, it's all just a name...
In JIRA, you can have as many Issue Types as you like and you can call them whatever you like. If you prefer the naming convention of Requirement over User Story, feel free to use that instead.
So procedural question about breaking down Epics...who typically does this? I've worked at companies before where the PO was responsible for getting down to the Story level. My current company we seem to be getting Epic level only. That doesn't seem like the correct process
So keeping with the hierarchy: Epic -> Story -> Sub-task. What is the most efficient way to track sub-tasks during a Sprint if they cannot be seen in the backlog? Meaning if I break a story into smaller sub-tasks, but not all the sub-tasks are completed prior to the end of the Sprint and has to be rolled over.. how would you account for that? It's not like you can see them in the backlog...
Question about estimating Epics vs Stories:
If, in the beginning of the project, user stories are typically of Epic proportions, do you use the same scale of story points between Epics and User Stories (be it T-shirt sizes or fibonacci numbers)?
In other words, would Epics be in the say 8, 13, 21, 34 range while user stories should fall within the 1, 2, 3, 5 range?
Or, do you use the same fibonacci range 1, 2, 3, 5, 8 for both Epics and User Stories, but assume that they are at a different scale when used at the different hierarchical level?
How do these two approaches affect Jira reports and velocity calculations, if different?
How would you organize the following scope of work in JIRA? What type of issue would you use?
Graphic of expenses
Ill interpret it in the following manner.
The product owner wants to add a capability to visualize expense in the product.
Id treat his need as a Feature, and capture it as an Epic, and explain the high level need for this feature.
User Story 1 - Web
User Story 2 - Mobile
Ill next add the task and stories to a Sprint to track delivery to production :)
Bottom line is - JIRA schema could be set different and its setup adaptable to the company needs.
I have worked with different JIRA schemas with different companies in the past.
Out of all of them the best one (and the one that make most sense to utilize JIRA's options) is this:
1. Epic (organizational break down, something that only one part of organization is working on and the other don';t need to see. For example different software type - core team and customization team could have different epic. or 2 different apps)
2. Under Epic goes your Project - whatever is your PM tries to implement - usually driven or created by PM.
3. Under Project goes - your Stories - those are driven or created by BA pr Product manager and they are cover your Requirements (user stories) - what they want to see once project implemented.
4. Under Stories go Tasks, they are Engineering tasks - what Dev will do to fulfill the Story/requirement.
5. Under each engineering Task go sub-tasks (for example QA specific). And if QA cannot complete Sub-tasks because issue is found - they link it to this specific sub-task. That way Dev sees what his tasks blocked by, as he cannot close the task without close all sub-tasks first.
In this setup everyone under the same Epic working on the same product or client or whatever you setup. It is easy to find your specific project and everything else cascade down from the project, so it is easy to see truck, find and analyze through JIRA tools.
I am answering this from a coaching point of view. This is how I try to explain in my sessions. I use the SAFe structure . Epic is something that you cannot touch and feel, Feature is something that you can touch and feel and experience, Story is we all know which abides by 3Cs and INVEST and finally task is technical nature to achieve the story.
Note that there are two flavours of "task" in Jira by default (although you can configure more):
The latter is intended to be used to break down a Story into multiple technical implementation tasks assigned to different people. Sub-tasks are a special kind of issue in Jira that can only live as children of a parent issue. On an agile board you can chose whether or not to show sub-tasks.
There is some debate here on when to use the former. I advocate for using a Task to represent work by the team that doesn't relate directly to a specific user story, e.g. implementing tools that help the team work better.
The tasks of Scrum are best represented using Technical Task sub-tasks as that works best with current Jira features.
For our team we had to decide on one of two options to deal with this:
What we've ended up doing is option #2, unless we anticipate before the sprint starts that a User Story is definitely way bigger than can fit in one sprint and preemptively break it up into smaller stories.
>The problem with sub-tasks is that you can't include sub-tasks in a Sprint independently.
That's not a problem, it's correct. A sub-task is part of the story you are telling people you are going to complete during the sprint. You do not commit to doing part of a story in a sprint, it's either going to be done or it is not.
@Mars- your approach is pretty much right, except that you should emphasise doing point 1 before you draw anything into the sprint!
The literal meaning of those three words are also actually what it means in JIRA - their meaning and their features.
Take an epic from a history - it will be formed of many stories - and each stories may have their own events ( tasks)
I understand it as simple as that.
Thanks for you varied answers to a basic question -- As an Agile practictioner for many years, I too am struggleing to get a consistant glossary of JIRA terms vs Agile terms -- and being able to transition from other tools to JIRA -- (not so simple).
I also am struggleing to uncover how to map deliverable features to components -- which is not a clear mapping -
The tutorials are lacking, as they do not conform to the Scrum Alliance or SAFe descriptions -- which is challenging as I attempt to teach teams about Agile, not just "JIRA"
I will continue to 'troll' the boards here to learn how the JIRA flavor of Agile can work.
I am also new to JIRA.
I found it conveniant to declare:
EPICS as the customers (name of customer).
Stories as the progress for each customer.
Task - user handled (not scram) that can break appart the stories into parts.
I create a project (A Goal, that leads to the whole sale for customer, such creating a sales' web-site for the customer, or adding terminals use abilitites, etc.)
When I create the project, and an issue in the jira cloud, I just drag+drop the stroies to the epic, and it is related to the story (in backlog tab, after clicking epic and version on the slide bar).
Version - I am using right now only one version (1.0), but if I enhanced the web-sie, i.e - I will call it the version of my whole product.
This is not an answer but suggestion.
I have used Microsoft's VSTS for quite some time. And the good part that they have done is to have hierarchy of Epics -> Features -> Product Backlogs -> Tasks/Bugs
Now with Jira, what is being suggested here to use story and tasks as per their intended use which as per the accepted answer is
Story = Requirement
Task = Steps to achieve the story.
Story and Tasks cannot be linked. We can create subtasks but then it does not appear clearly in a hierarchical structure in display which VSTS does pretty well.
If we can have a structure like Epics --> Features --> Product Backlogs --> Tasks/Bugs structure and also their display in hierarchical format, it will be very useful
Jira is a versatile tool that you can adapt to your understanding / way of using user stories
I really recommend you to read the book User story mapping "https://books.google.be/books/about/User_Story_Mapping.html?id=4YZyBAAAQBAJ&printsec=frontcover&source=kp_read_button&redir_esc=y#v=onepage&q&f=false
by the person that invented the term Jeff Patton ...
A user story is a way to help the common understanding of a user need for both business and developers ...
so it needs to be formulated in very specific way to create the needed effect:
" As a user X (replace X by what the type of user is : guest, member, new ... whatever makes sense / also called personas) I need to be able to do (/find / create - include whatever action is relevant) Y (Replace Y with the desired think that user needs to do), So that I can achieve Z (replace Z with the business objective for the user)."
All questions asked by the developers or users on the story, and the answers given become clarifications and are converted to acceptance criteria (defines when a story is done)
The main issue I have here is that the tools proposed in Jira to do this very important work are nowhere near what the business side people can use to help define these stories ...
Is it in the plan to offer this some day ? (until then we work with third party tools like stories on board)
I agree with @Mars
"The way I've been approaching the distinctions of issue types is this - I'd LOVE some feedback or alternative suggestions to consider:
I can only add:
Some Agile to PMI terminology
Epic - Project (PMI): A work breakdown structure (WBS) of a Project.
Story - Sub Project (PMI) or Line Item on the WBS: A subgroup of items or a single item in the WBS related to the same activity.
Sprint - Work Execution (PMI): Work towards a kill gate or milestone.
Scrum - Meeting (PMI): Typically, this is once per week meeting and not daily since one-on-ones are expected between PM and Team Member on a daily basis.
Velocity - Budgeting (PMI): PMI uses Earned Value Management which tells you far more information than velocity ever could.
Scrum merely renames things from the Project Management world. There's nothing new under the sun, as the saying goes, and even PMI is an extension of PM activities from 2,500 years ago (Pyramid construction).
"Scrum merely renames things from the Project Management world." - oooh no no no, that's utterly wrong.
You're also wrong about almost all of the parallels you draw. Story is not far off, but your comparison of Epic, Sprint, Scrum and Velocity are all wildly wrong. I think you need to have a proper look at the Agile manifesto and Scrum (and the other methodologies it lends itself to)
The biggest misconception about stories/tasks is that one story generates N tasks, where each task is based strictly on one story. This is almost never true. A collection of stories generates a collection of tasks, where each tasks belonging to only one story is a rare lucky special case. But more likely you cna have 2-to-3, 5-to-1 or 13-to-17. Drop the idea of tasks being children of one story and you're golden.
A collection of stories describes some software change from the user perspective while a collection of tasks describes that same software change from the development team perspective. Conversion of the former to the latter is usually what they call sprint planning.
Don't enforce hierarchy where there is none.
As for sub-tasks. In my team we simply agreed to not use sub-tasks due to a very confusing name: they're not a task granularity organization tool actually, despite the name. Sub-tasks are a redundant, unnecessary and misleading concept imho.
Stephen - I appreciate your comments here, just as the PMO side of our teams has just brought the following (invented) SDLC/AGILE Edict into Law: Each Story will always have: (1) RQ Task; (2) Test Task(s) (QA); (3) Coding & Developer Task(s); (4) Test Automation Task (QA); (5) Release Task; and possibly more. Along with this, an additional set of articles for each transition, that states "...a JIRA Story cannot continue to the 'next status' until Task N is completed, and Done...". So, now after having shortened our Scrum workflow from 13 statuses to around 7, we're now looking at the workflow going from the 7 statuses, to close to 20! I've given my feedback, but now just watching the team make committee decisions. Thoughts?
My thoughts, given my previous post, is that what you have is not really stories anymore, since they're already pre-digested into macro-tasks for the developers to split into sub-tasks by role/discipline/sub-team. "True" stories are something that comes from a pure user perspective with theoretically zero knowledge of the implementation. To write real stories you need to "forget" you're working for your own company.
Then again, the fact that all your stories are "standard" and usually result in the same collection of tasks in sprint planning is also nothing illegal. From that perspective your model seems perfectly fine.
Seven statuses sounds like much but I guess your workflow justifies that.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events