I'm aiming to get through this at about
half the time to save some time at the end for like really
specific questions. A lot of this is going to be high level
overview stuff so at some point in the next six weeks or so,
I’ll do a JIRA 201 Class were we talk a little bit more about some of the advance
stuff, JQL, administration and stuff like that. But we will start right here just to make
sure everybody is starting with a good base understanding of JIRA. I’ve met most of you but there’s a couple
new faces in the room so just to make sure everyone knows who I am,
I’m Dan Chuparkoff, this is my wife. I lead marketing for the JIRA Family. That bridge is the big orange one over there,
it’s foggy all the time anyway so it never looks like this. Okay, so also a little bit something
about me, like I track everything. I spent the last 15 years or so really, really
entrenched in the issue tracking space. I use it at home, I use it at work. Before I was in Atlassian, I was looking
for a replacement for my company, for my Microsoft project for like eight years
and I tried about every tracker on the market. When I finally found JIRA,
I really, really liked it. It was really close to what
I’d been looking for a long time. And it was really, really hard to find so I decided
to come here and help tell the world what JIRA is. A little glimpse into my personality. This is Thanksgiving Dinner
at my house in 2002. There’s a project plan, like my Aunt
is assigned to something, my Sister had a task here which
she had to do at exactly 3:58. She was freaked out all day, she carried
a clock around with her, it was awesome. But we ate dinner at exactly four
that day and so like when I first went, I was having Thanksgiving,
like every year for my whole life, and every single time it would
be like 5 o’clock, 5:30. We said we were going to eat at four. My mom
has no idea what time she’s going to be done. She’s made this same exact
food every year for like 52 years. How is she still not able to estimate when
Thanksgiving Dinner is going to be done? So at the same time I was learning how
to use Microsoft Project and I was like, “I wonder if that would help?” So I actually made dinner this way for three
years in a row and it was a cool exercise. Anyway so I use JIRA at home.
This is my personal JIRA instance. The stuff here, it’s sorta
like my to-do list stuff. Like if somebody sends me an article, "Hey, read this
mashable article, watch this Ted," I put it in JIRA. I keep that mixed together with
the stuff I’m doing for Atlassian. My goal is to make sure that my home stuff and
my work stuff is both going up at the same rate. If I start to do too
much Atlassian stuff and not enough home stuff this graph
helps me see that as a problem. We are going to talk about JIRA 101
and how I have taken some of those deep rooted personal issues
and applied them too my job. We’re going to talk about
some basic Agile stuff first, then I’ll go JIRA Agile Planning
and Workboards and Tracking. Then we will talk about JIRA issues and searching
and Dashboards and things like that. And what I am not going to talk
about it in here is JIRA Administration. One, none of you are admins on EACJ so you
won’t be able to do those things anyway. And two, that will be the next class. Alright, so first we will talk about
some basic Agile concepts. In about 2000, development teams were struggling
with the same problem they been struggling with for 20 years and that was
projects took way too long. Back then it was 18 months was
a general software delivery project and you would spend a year working on the requirements
and then you would start that 18 month development thing and then you would finish it
and two and a half years had passed and the thing that you set out
to design was a little bit obsolete. So people were trying to create a method
of reacting to change a little bit better and planning in smaller doses instead of big huge
18 month batches and so they invented Agile. What they sorta discovered is with Agile
work management, not just software, and Agile task management,
and Agile relationships with people, better visibility solved
a lot of problems. Just writing down and posting
the things people were working on. It raised visibility of what was going on. People
prioritization discussions were a lot more clear. Prioritization was one of the things
that resulted from this. Less downtime between tasks was something also.
It was before we had strong task management things. People would sorta work on something for awhile
and finish it and then they would be like, "Ahh, what should I work on next?" And they would sort of look at everything
that was still outstanding and they would figure out what
the most important one was. That downtime between
tasks multiples over time. Tracking systems help you make sure you are
minimizing the time between actually doing work. Improved teamwork is another
side effect of this. When you put all of your teams work in one
system and you are sorta self assigning, grabbing work as it is needed
from the top of the list you get a lot better collaboration between
people that all have the same goal. And then finally, more predictability. Right,
if you start actually estimating the tasks you do, even if you are not a developer,
estimating the work that you do, and figuring out, can I really do
these eight things by next Friday? Over time as you try to do that, over
and over and over again you start to get a really good understanding of what realistically
you are going to have done by next week. So creating tasks
we will start there. Outside of the development space the thing
people struggle with the most at first when they are trying to use JIRA is understanding
what to put into JIRA as a task. So what is a task in the first place?
Like doing a case study, making a promo video, doing some market research,
those are some of the things that instinctively people will initially
put in their JIRA. And then they start to realize, "Hey, I’m doing this
case study and it’s not done, it’s still in progress, it’s been in progress for like 13 days now
because I’m waiting on someone to review it and so that's a task that sits in progress
for a really long period time and that’s bad”. Making a promo video is another one
of those things, hey we do the script, we get the customer signed up we
wait for the video guys to come in, so they aren’t going to come in for two and
a half weeks so again that task sits open. Market research is another good one,
we do some specs first the we wait, anytime you are waiting,
that’s generally... you can’t wait in the middle of a task,
you just do a task right, so that is a sign that you are probably talking about
a collection of work and not just a single part. My rule for finding that problem is this,
so when you are defining tasks always try and make sure they
take more than 30 minutes to do. If it’s just like, ‘hey go get my lunch from the New York
area’ that’s too short to work or write down. If it is bigger than 30 minutes though
it is probably worth recording because organizing those to make sure you are
working on the right 30 minute things everyday is probably a good idea. And then second, don’t make a task
that is more than three days. Personally I don’t do a task
that is more than one day. So that my stuff, so that I’m actually able
to shuffle my prioritization every single day. At first aim for these two targets. And as you get better at estimating over time
you can tweak those to suit your own needs. So the second thing here that
you will struggle with at first when you’re trying to put stuff in JIRA
is the thing I allotted to a second ago. So, I have this write a blog task on my plate and
it’s going to take me probably two weeks to do because I am collecting information from
a lot people and I am writing a draft and then I’m my team review it and then I’m
editing it and then I’m publishing it in Word Press. That’s not one task,
that’s a series of five tasks. And so, anytime you see yourself waiting
on a task you think you started already, look at it closely and figure out
if it is really a series of tasks. Work should be binary, you’re either in progress
doing it or it’s done or not started that’s the goal. Next, estimating is really important part of this
process, so as you are trying to figure out work, try and understand if it’s a two hour thing
or a five day thing, that’s pretty important. JIRA uses the concept
of story points and not hours. Generally story points
look something like this where you don’t go really super
granular, do sort of a doubling effect. Some people use different
numbers that are like primes, I do this because it is easier
to frame in my head. As you are trying to figure out if your task
is little tiny things or big huge things. Another thing I do is sorta story
point cheating, which Agile.... Agile, passionate Agile people would
yell at me for having this slide. But like the smallest task I will
put in JIRA is a 30 minute thing so clearly that has to be one story
point so that is lowest I can go. And I sorta of....three days is my limits,
so 48 is my biggest number and I sort of every half hour 30 minutes
and so as you are figuring stuff out your one hour things are two points
and your one day things are 16 points. As you do that you will get really
good at figuring out realistically how many of those things you are
going to be able to do in a week right because there is a very
clear estimate translation. Is story point an Agile Concept?” Story point is an Agile Concept yes. So what they tried to get away
from is hour estimates right because as soon as you do
hour estimates and you put this task is going to take me two hours,
but then you do time tracking of some kind and it takes you two and half hours, somebody looks
at that and says, "Hey, you are working too slow," right. So they tried to make and obscure
number that was harder to translate so that when people were
first doing estimating it didn’t turn into something that bosses
looked at to judge performance. That’s why it is deliberately
obscure from hours. There’s a bunch of different
ways to do it. At first as you are trying
to figure it out instinctively you’re going to be
gravitating to figuring it out as, is that a half day thing
or a full day thing. Just have a number
in your head that means half day and full day because
that is the important part of this concept. If you are mixing work between your team it’s
important that you are all using the same scale. If a half a day to you is 8 story points and
a half a day for him is 27 story points then your teams work mixed together velocity
mixed together won’t make sense. Has everyone seen this screen so far? Has everyone
created a JIRA issue at some point so far? Alright, I won’t spend a lot of time here,
there’s a button at the very top of JIRA that says create issue, you get
this screen when you do it. If there is a field you want to type that
isn’t there you can click ‘configure fields’ and if it’s one of these choices
you can add it to the screen. When you do that, everyone else on your team,
in your project will see that field as well. One more thing that is really
important to sorta understand before we get into this is the difference
between Scrum and Kanban. Scrum and Kanban are subsets of Agile,
they are two different types of Agile work. The difference is this, so Scrum, Scrum is used by teams that target a deadline
that they are trying to work toward. It’s a release that comes out,
a client deliverable, it’s something with a fixed date and
they are trying to manage toward it. The least important variable for a Scrum
team is quantity of work that gets done. Date that it releases is generally
more important than what is in it. A team that has a release coming out JIRA 6.4
at some point they will have to make the decision, hey this one thing is still broken,
I either need to move that date or I need to take this broken
thing out of the release. Scrum helps people manage that. The batches of work that
people do are called Sprints, and we will talk a little more
about that in a minute. Kanban teams are like Scrum teams except they
don’t have a target date that they are working toward. Support and Service teams
are generally teams that have a list of work that's always
getting new items on it, prioritize it and work through it
as fast as they can. With a Service team as they are looking
at tickets, how many of those tickets are going to be done by next Friday is way less
important than making sure they are in the right order and that the team is working
through them as fast as they can. Kanban doesn’t have a plan mode, so when you are in JIRA Agile you will see
this Plan Mode button is greyed out, you can’t click it, you don’t do planning for Kanban
you just prioritize and work as fast as you can. Your to do list in your Kanban board
just goes on and on forever, where as in Scrum your to do list is only the list
of things you have decided to do in this sprint. Now let’s actually show you some screens.
This is the Plan Mode of a Scrum project. Kanban doesn’t have a Plan Mode, this is the Plan Mode
of a Scrum, this is my Home Instance. Initially you start creating issues and you
end up with a bunch of stuff in a back log. You create a list of all the things
your team wants to do, doesn’t have to be the list of stuff for now,
it can be stuff you’re not going to do two years. You create all those tickets
and they end up in the backlog. The second thing that you need to do
is figure out if you want to use Epics. So these are Epics. An Epic in JIRA is more
like a theme for that collection of work. The Agile team is working on making some changes
on how that works so that it is a little bit more of a.... a bucket that can truly contains tasks.
Right now it is more like a tag. I have some things in my own instance;
I have an Epic called Books to Read. All of the books that I have on my list
have the Books to Read Epic. At any point in time I can click Books to Read over
here and it will hide everything accept that. It gives me a quick way to visualize
all the work of a certain theme. Exactly like a tag, yes. Exactly. Components are...well the first answer
is it’s called JIRA Agile Epics needed to be in there somewhere
so we called it that. Structurally under the covers it’s not
that different from components, it’s just another type of tag that
you can put on an issue. The biggest difference is that
because it’s an Epic you can click these filters and see just
the things for that particular theme. Once you have a task and you’ve put them in Epics
then you start picking the things you want to do next and you drag them up here to the next Sprint.
This is how prioritization works in Scrum. Typically your backlog is big long
list with hundreds things in it. Putting that huge long list in order
by priority is generally not that effective but picking the things you want to do
in the next batch is really important. Grab the most important things;
put them in the next Sprint. You can actually start working and
bucketing your stuff in advance. Creating a new Sprint in this list is as easy as clicking
the Create Sprint button and giving it a name. Two week Sprints is a pretty good standard.
Usually one week Sprint is too fast, you are starting and stopping Sprints so often
that the administration is not worth it. Two weeks is a pretty good number.
One month or six weeks is a little bit too long because what starts to happen
is your Sprint is six weeks long and you get some new
request for new work that has to be done right now, you're adding
stuff to your Sprints all the time. Two weeks is a good place to start,
you may tweak that. “How do you handle task
dependencies in JIRA?” First you can link tasks together in JIRA.
This particular task can be linked to this other task. This system doesn’t enforce that other is done first.
People have to self manage the dependencies. JIRA will indicated that there
is a dependency but it doesn’t help you make sure those
things are all done first before you start. “So if I drag something
up into the Sprint, can we enforce that something else,
a dependency, is done in advance?” Correct. Actually by dependence,
JIRA allows you to link two issues but JIRA doesn’t know if you mean this one has
to be done first and this one second or vice versa. It just knows that those
two are related. I’ve dragged stuff up. The other thing about two week Sprints is that
in a year there are 26 two-week Sprints and that are exactly how many
letters are in the alphabet there are so it’s really convenient for me
to use letters for my Sprints. So when we are talking about which Sprints we should
do things in everyone is on the same page about we’re talking about H or Sprint I that’s really handy,
if you’re thinking of names for your Sprints. “Is the typical way to create your Epics first?
Do you go top down or bottom up?” I generally create my Epics first.
I create my Epics first because that’s the thing that tells me
what kind of stuff I should be doing. I know I wanna be....So at work my Epics
are ‘do stuff to support the experts, do stuff for email, make changes to WAK’,
things like that so I makes those first then I figure out, ok we are going to do email stuff,
what do we need to do for email stuff next? And that helps me, the Epic helps me
figure out where to put my energy. If I create tasks first, I’ll think of an infinite
number of things I’ll want to do to WAK and that will fill my whole entire plate
and I will never get to expert things. So I do expert things first to make sure
my work is evenly balanced where I want it. Once you start a Sprint, you start
a Sprint by clicking start at the bottom and I have already started this one here. Once you
have an active Sprint you start working in Work Mode. Work Mode looks like this.
You have columns. I won’t spend a lot of time on how
this works because it’s pretty intuitive, you just drag from left to right,
you can go back if you decided, "Hey, I was working on this but I actually stopped’,
you can pull it back over. Pretty intuitive. When you click the project name
you will see the detail for that task in the little pane that pops up
over here on the right. The question that some people have next
once they start getting in here is the say ‘to do in progress and done is nice but
I have a review stage for the work that I do, or I have two teams that are working
together like a DEVE team and a QA team, I do some work and then I pass it over to the next guy
then he does some work then he passes it back to me’. That’s Workflow inside of JIRA.
You can have...Workflow is infinitely complex, we have a customer in Massachusetts
working affiliated with MIT, there doing genetic
testing using Workflow. They have literally 8000 columns in their Workflow.
They can’t display it on a board like this but under the covers have literally 8000 steps
for each of the decoding parts of the process. So you can make this a complex
as you want. I will caution you however, all the work that you do should
follow the same Workflow. This is to do, in progress and done because anything that I could possibly
imagine doing fits into that Workflow. As soon as I have something’s that say, like for
books, books say maybe the book that I want, get it from Amazon, read it,
tell people about it, it could be like that but as soon as I have some
other thing like watch some YouTube Ted, then it doesn’t fit into that Workflow
and I need to manage two boards. As soon as I have two boards
and four boards and six boards then there is no one place I can go
to look for the work that I have to do. Don’t get too crazy with how
many Workflow steps you want. “Is there a way for me
to have a waiting task? I feel like with a lot of tasks you
do a task and then you wait,...” My personal belief on that
is that’s always two tasks. I prepare the draft of the Road
Trip Deck for Jay and then I have a second task that says
Incorporate Jay’s feedback into Road Trip Deck. That will always be two tasks
for me. The waiting is always... I don’t know how long the waiting will be.
I can’t work in the thing until I get it back. I’m not actually managing that other
person’s time of waiting, of the review. All those things really....
I do the draft and then I have the... and then I accommodate the feedback task.
Highest on the list in the next batch, so as soon as I get that feedback
I can start on the second half of that. I never have a waiting step but with
blogs here, when we manage our blogs here in the HCJ we do put a review step in
there so it is possible to do it. I typically don’t. I’m not in control of the people I am waiting
for and my number one priority is I don’t wanna have things in my in progress
column that I’m not actually actively working on. “Realistically you have things
with lots of subtasks. If it’s more than ‘get a book
and read it’ what do you do?” Prepare for the Road Trip is a collection of tasks.
I could give those a particular Epic. The Epic I use in real life is ‘We have Atlassian
Events Epic and I have Non-Atlassian Events Epic’. When I click that Atlassian Events Epic,
I’m going to see all my Road Trip tasks in that view. I’ll see the ones that I’m actually
working on at the top; I’ll see the ones that I haven’t
started yet further down the list. I might start seeing some
at tasks at some point but they’re really in the same list and
I should look at them together really. If having them all mixed together is confusing then
I would create two Epics to help separate those. In this particular view I’m really only concerned about
the things that I am supposed to be doing by next Friday and the things that I am
actively doing right now. The other thing is that at the very
top there’s quick filters so you can see only issues,
or my issues recently updated. You can create additional quick filters
that show you things of a particular type. “In this Scrum board you
have multiple Epics, so you may pull up a Sprint and
so you’re mixing your work?” Yes, absolutely. Almost always.
What I'm attempting really is to make sure that with each Sprint I am advancing all of my
Epics a little bit in my particular context. In a developers world they
may want to focus on one Epic and knock it all the way out and
then move on to the next one. In my context I’m trying to evenly distribute
my work across all the channels I need to support. Next I will talk about Burndown.
Burndown is probably the most important graph or thing
people would look at in JIRA. Burndown, once you have created a bunch
of tasks and you have put them in a Sprint and you have started that Sprint, your goal
is to take all those in things in that Sprint and get them done by the end of that Sprint. In our case a Sprint is two weeks, at the beginning
of the Sprint our team collectively, the four us created 600 story
points worth of work. That 600 story points worth of work divided by four
of us is telling us there is about 150 points each that were trying to do and I know from out teams
velocity that we generally only do 120 each. We probably failed they very first day of the Sprint
already. You can see that we are proving that that is true because this line is our actual progress
and this line is what we should be achieving. In the next two days we still have
to finish 500 story points worth of work and these guys are screwing around here
not doing any work at all. So this the Burndown, what you’re really looking
for here is nice even downgrade so that your accomplishing
things over time. What you will see when you first start doing this
is you will see a start and the you’ll see lots of up. An up line slope means you started your Sprint
and then you added more things to it. When you add more
things to your Sprint your ability to finish what you thought
were going to finish starts going down. When you add something to a Sprint
ideally you should take something out, if you don’t, you are either not going to finish
what you thought you were going to finish or you’re going to be working
on the weekend. Both of those are normal occurrences
but that’s what the up line means. The second thing that you are going to see
is that a bunch of horizontal like this, then you’re going to see that at 1:30,
after these guys get out of this meeting their going to go back and close all
the tasks that they forgot to update and then I’m going
to see a big cliff. Those are the two things that
you will see in Burndown. If you have the opportunity to display
on a TV near your team make sure everybody is watching
this graph over time. It really helps your team estimate
better, it helps you figure out what you are going to accomplish by the timeframe
you think you are going to accomplish it in. None of this is about making promises
to our GM about what we are going to finish. This is about getting better at estimating
at what we think we are going to accomplish. “One of the problems we have is that we estimate
and the it takes longer than we thought ...” Two things about that, first that happens
to everybody when they start estimating at first, probably in your past you never ever
had to estimate things that you did so you probably suck
at estimating at first. That’s why story points
is more useful than hours because it doesn’t matter if you
think four story points is two hours. What really matters is that you
finish story 50 points a week. Whether think that’s 100 hours
or 40 hours doesn’t matter. You can look at this graph over time
after your Sprints and we can see ‘ok, you guys are only doing 50 points each,
you think you are going to do 80 points each’. Each time you start a new Sprint you should
lower the number you are starting with. It doesn’t actually matter if your
task takes the right amount of time. What really matters is that your
total amount of story points is a number that matches what
you have delivered in that past. “Wouldn’t, depending on the task, wouldn’t your ability
to estimate it change... because of its complexity?” Correct. That variability is
always a part of this definitely. What’s generally true is that
amount of easy things and the amount of hard things on your
plate is fairly consistent over time. It will waffle back and forth but after you’ve
done a year’s worth of Sprint estimation, when you look back at year
and see your average velocity is the number of story points
you can do in a Sprint, after looking at for a year
you’ll be able to see pretty clearly about the same number
of points done every time. “Do we have a library...Because you know that if you’re doing A,
ever time it’s going to take two story points...?” There’s not a way to do that here
although you can clone an issue but that finding the old issue to clone
is probably more effort than it’s worth. Generally what happens is
people over time start to say, "When I do a blog that’s probably realistically 16 points,"
and they just know and you just get better. “How do you account for interruptions? Something
comes up, small...robs your time...but its small?” Those happen for sure. The reason I only
get 100 story points done in two weeks is because I’m doing a lot of stuff
besides the stuff that’s on this list. Those interruptions, when they
are consistent over time, those interruptions will be truly
reflected in your velocity. What’s bad is when over a course
of a month, right before summit; people go up to Rudy like every
four minutes and ask him questions. Then three weeks after summit is over he goes through
a period where he’s in more control of his time. Rudy’s ability to estimate his
interruptions is hard and a lot of us have those same type of rollercoaster
type interruption patterns. There is nothing in JIRA that
will help you manage that. JIRA and most Agile trackers are assuming
whatever the variables are in your workday, whether it’s easy stuff to estimate or hard stuff
to estimate, easy stuff to do and hard stuff to do, interruptions, the time of day you work,
how many weekends you do... Most Agile trackers are assuming
that all those variables are just constant across
a year’s worth of time. So when you do a bunch of estimation
as best as you can and then look at the total velocity that you accomplished
it’s probably pretty close to true. When you are planning your upcoming things
look at how much you accomplished in the past and try to plan according
to those things. The next thing I was going to show
you is JIRA issues in Dashboards. Once you have work in JIRA,
looking at the work in Dashboards, aside from the work you are actually doing,
day to day you are usually looking at Work Mode. You’re looking at the tasks you are doing,
you’re moving the tasks closer to done. If you are interested in what
your team activity is, if you are interested in the work other people are
doing JIRA’s Dashboards helps you do that. This is a basic JIRA Dashboard. You can drag and drop these sections around.
You can add new things to the list. There’s a gallery of things you can add.
This is my home one again, you can this is focussed on
things I am doing for home, things I am doing for work and then quick
access to the lists that I go to often. If what you are looking
for isn’t there what you will generally want to rely
on next is Searching for Issues. If you click the Issues, you can’t see
the top menu but it says Issues. If you click that, the first thing
on the list is Search for Issues and once you click that Search for Issues
you end with a screen that looks like this. There are two ways of searching
for stuff in JIRA. The first way is called Basic Search
and if you have Basic Search enabled and that will be the default you will end up
with drop down boxes here at the top. You just pick a project, you pick status
and you pick by picking check boxes. There is also a more
link somewhere over there. When you click more, everything that
is in your JIRA Instance is a choice. If it was on the Create Issue screen as something
you can put in it will be in that filter drop down box. Creating a collection of issues to look at
is pretty easy to look at with Basic Search. As you get more complex you’ll wanna
maybe switch to what we call JQL. JQL in our vocabulary
is JIRA Query Language. Typing it is pretty easy, you just start
typing and it will give you suggestions. So up here I typed project and right after
I typed project I got a list that looked like this and I could pick equals from it, as soon as I hit space after it equals it gave me
a list of the projects that were choices. You can start typing and it will suggest
whatever you’re possible choices are. It’s really easy to start creating a query
that gives you a complex list of issues. You can combine different
projects together like this. You can look at projects that
lots of people are doing. You can just look at your stuff.
I can just look at Jake’s stuff. Whatever you want.
This is how search works. All the gadgets on the Dashboard use Search,
all of the Quick Filters on your Agile Boards use Search. Go to Issues and Search for Issues and play
around with the search mechanism a little bit. You’ll see when you try to go to do other
things on Workboards or Workflow that you’ll need to know how to do
JQL either in basic form or advance. That’s Searching, that Work Mode,
that’s Plan Mode, that’s Creating Issues that’s pretty much it and now I can
do questions, as many as you like. “Is there a mobile app for JIRA?” That’s a great question. Last May we released
the HTML five version of JIRA Mobile. There is app, it just works on a browser on your
phone so if you go to EACJ on your phone and log in just like you would at your desk
you will get a simplified version of interface. It’s designed to show you the things
that are active for you, so you can look at your list and see what’s
in progress, what’s important, what’s critical. The second thing that it is designed for
is when you’re on your phone away from the office and somebody tags you in
a ticket, you get an email and that has a link, and you click it, we wanted
to make sure the things that you got when you clicked the email
was readable. That’s its real job. “In Confluence you can create tasks...Has there
been thought about how those tasks relate to JIRA?” Ya, for sure. In the beginning of February
or late January Confluence 5 2 came out 5 4. There was a project we
code named Coat Hanger. One of the features of Coat Hanger is
to take a list of tasks in Confluence, if you select the text
and right click it, you get a little JIRA icon and it will
suck it into JIRA automatically. It’s pretty cool. The design and this is pretty
important from and Atlassian messaging perspective, the design is that a team will collaborate on
requirements together as a team in Confluence and they will take an idea and turn it into
something has fleshed out specifics. At some point in that process that list of requirements
turns into a list thing you want to do. In Confluence you end up with a list,
you suck that list into JIRA automatically it creates the list of things
inside and Epic in JIRA. Then you assign that work in JIRA, then
using the Create Branch link inside of JIRA you can immediately
create link source code to the issues in JIRA which are linked
the required documents in Confluence. So, end to end concept to launch with
very few click those integrations work. That’s it. As you guys get started
and start playing around definitely come find me if you have
any questions. Thanks coming guys.
