Introduction to JIRA & Agile Project Management

I have lots more in store. Follow me on Twitter for more great stuff: http://bit.ly/ChupTweets
Join me for a brief introduction to JIRA & Agile Project Management. I'll talk about basic Agile concepts. I'll show you basic JIRA planning and working with Scrum and Kanban. And I'll show you the most important reports to master so you can build great software just like Atlassian. The corresponding presentation deck for this talk can be found on Slideshare: http://www.slideshare.net/chuparkoff/...

---

Closed Caption:

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 it 02 01
class where we talked a little bit more
about some of the advanced stuff
j ql administration and stuff like that
but we'll start here just to make sure
everybody's starting with a good base
understanding of Europe
um I've met most of you but there's a
couple new faces in the room so just to
make sure everybody knows who i am i'm a
dancer park off this is my wife
I lead marketing for the jira family so
I that bridge is a big orange one over
there it's you it's foggy all the time
anyway so it never looks like this
ok so I also a little bit something
about me like I I I track everything
like 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 I've before i was in
atlassian i was looking - looking for a
replacement for my company for microsoft
project for like eight years and I tried
about every tracker on the market and
when I finally found jira I really
really liked it was really close to what
I've been looking for for a long time
and I it was really really hard to find
so I decided to come here and help tell
the world what your is right
so a little a little glimpse into my
personality right so 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 hear what she had to do at exactly
358
she was freaked out all day she carried
a clock around with her
it was awesome but we ate dinner at
exactly for that day and so like when I
first when I was having thanksgiving
like every year for my whole life right
and every single time would be like five
o'clock
530 we said we were going to eat it for
my mom has no idea what time she's going
to be done she's made the same exact
food every year for like fifty two years
right
how is she still not able to estimate
when thanksgiving dinner is going to be
done
so I at the same time I was learning how
to use microsoft project and i was like
i wonder if that would help and so I
actually made dinner this way for three
years in a row and it was really a
wizard cool exercise anyway so i use
JIRA at home
this is my personal gear instance the
stuff here is stuff that I'm it's sort
of like my to-do list right like if
somebody sends me a article like hey
read this
mashable article watch this TED I put it
in jira I keep that you know mixed
together with the stuff I'm doing for
atlassian and so 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 I I this graph
helps me helps me see that as a problem
alright so we're going to talk about
jira 101 and how I've taken some of
those deep-rooted personal issues and
apply them to my hand
my job we're going to talk about some
basic agile stuff at first then i'll go
through jira agile planning and work
boards and tracking and then we'll talk
about your issues and searching and
dashboards and things like that and what
I'm not going to talk about in here is
your administration one
none of you guys are admins on da CJ so
you won't be able to do those things
anyway
and to that will be the next class
cool
alright so first we'll we'll talk about
some basic agile concept so I in about
2,000 development teams were struggling
with the same problem they've been
struggling with for 20 years and that
was projects took way too long
like back then it was you know 18 months
was a general software delivery project
and you know 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 planning in smaller doses instead
of big huge 18-month batches and so they
invented agile and what they sort of
discovered is with agile work management
not just software in agile task
management agile relationships with
people better visibility
I solved a lot of problems just writing
down and posting the things people were
working on it raise the visibility of
what was going on people
prioritization decisions were a lot more
clear um so prioritisation was one of
the things that resulted from this less
downtime between tasks or something also
it was before we had strong task
management things people have sort of
work on something for a while and they
would finish it
and
it would be like haha alright 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 and
that that downtime between tasks
multiplies overtime so at tracking
systems help you make sure you're
minimizing the time between actually
doing work improve teamwork is another
big side effect of this so when you put
all of your team's work in one system
and you're sort of self assigning
grabbing work as it's needed from the
top of the list
you get a lot better collaboration
between people that all have the same
goal
um and then finally more predictability
right if you start actually estimating
the tasks you do even if you're not a
developer estimating the work that you
do and figuring out can i really do
these eight things by next Friday
um 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're going to have done
by next week so creating tasks
we'll start there outside of the
development space
the thing people struggle with the most
at first when they're trying to use JIRA
is understanding what to put in 2 g.r 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 there 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 really long
period of 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
you know the video guys to come in and
so they're not going to be here for two
and a half weeks
so again that tax it's open market
research is another good one we have to
we do some specs first and then we wait
anytime you're waiting that's generally
you can't wait in the middle of a task
you just do attack
that's right so that's just that's a
sign that you're you're probably talking
about a collection of work and not just
a single part
so my rule for finding that problem is
this
so when you're defining tasks always
trying to make sure they they take more
than 30 minutes to do if it's just like
hey go get my lunch from the you know
New York area that's that's too short to
work or to write down if it's bigger
than 30 minutes though it's probably
worth recording because organizing those
to make sure you're working on the right
30 minutes things every day is probably
a good idea
and then second don't make a task that's
more than three days
personally I don't do a task that's more
than one day right
I'm 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 it first when you're
trying to put stuff in jira is the thing
I alluded to a second go 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'm collecting information
from a lot of people and I'm writing a
draft and then i'm having my team review
it and then i'm editing it and then I'm
publishing in WordPress
like 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's really a series of tasks right
because work should be binary
you're either in progress doing it or or
it's done or not started right that's
the goal
next estimating is really important part
of this process so as you are trying to
figure out work try to understand if
it's a two-hour thing or a five-day
thing right that's pretty important
so Jerry uses the concept of story
points and not ours
and so generally story points
look something like this where you don't
go really really super granular do sort
of a doubling effect
some people use different numbers that
are like primes and stuff like that
I do this because it's easier to frame
in my head
and as you're trying to figure out if
your task for little tiny things or big
huge things
another thing i do is sort of story .
cheating which agile agile passionate
agile people will yell at me for having
this slide but like the smallest task
however put in jira is a 30 minute thing
so clearly that's got to be one story .
because that's the lowest i can go and I
sort of do three days is my limit so 48
is my biggest number and I sort of every
half hours 30 minutes
and so as you're figuring stuff out you
know your one hour task for two things
in your one day things are 16 points as
you do that you'll get really really
good at figuring out realistically how
many of those things are going to be
able to do in a week
right because there's a very clear
estimate translation story . is an agile
concept yes
so what they tried to get away from is
our estimates right because as soon as
you do our estimates and you put this
task is going to take me two hours but
then you do time tracking of some kind
in it
it takes you two and a half hours
somebody looks at that and says hey
you're working too slow
right so they tried to try to make an
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 right so it's that's why
it's deliberately obscured from ours
right right right yeah so there there's
a bunch of different ways to do it but
like at first as you're trying to figure
it out
instinctively you're going to be
gravitating toward figuring out is that
a half day thing
or a full day thing right and so just
have a number in your head that means
half-day and full-day right because
that's the important part of this
concept and then if you're mixing work
between your team
it's important they are all using the
same scale right because if a half a day
to you is eight story points and a half
a date for him is 27 story points then
you then your team's work mixed together
velocity won't make sense right
ok so has everyone seen this screen so
far like has everyone created a JIRA
issue at some point so far right
I won't spend a lot of time here but
there's a button at the very top of the
area that says create issue you get this
screen when you do it right
if there's a field that you want to type
in 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 right
I one more thing that's really important
to sort of understand before we get into
this is the difference between scrum and
Kanban so scrum and Kanban are subsets
of agile
so there are two different types of
agile work and they
the difference is this so scrum scrum is
used by teams that have us a target
deadline that they're trying to work
toward so it's a release that comes out
it's a client deliverable it's something
with a fixed date and they're trying to
manage toward it right so that the least
important variable for a scrum team is
the quantity of work that gets done date
that it releases is generally more
important than what's in it
right so a team that has a release
coming out geo 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
police right and so scrum helps people
manage that the batches of work that
people do are called sprints and we'll
talk a little bit more about that in a
in a minute
combine teams are like scrum teams
except that they don't have a target
date that they're working toward so
support and service teams are generally
teams that have a list of work that's
always getting new items on it and they
prioritize it and work through it as
fast as they can
wright with a with a service team as
they're looking at tickets
the how many of those tickets are going
to be done by next Friday is way less
important than making sure they're in
the right order and that team is working
through them as fast as they can so I
can man doesn't have a plan mode
so when you're in jira agile you'll see
this plan mode button is grayed out you
can't click it you don't do planning for
can ban you just prioritize and work as
fast as you can
so your to do list in a Kanban board
just goes on and on forever
whereas in a strum your to do list is
only the list of things you've decided
to do in the spring
ok ok so now let's actually show you
some screens so this is the plan mode of
a scrum project right so can ban doesn't
have a plan mode
this is the plan mode of a scrum this is
my home instance right so initially you
start creating issues and you end up
with a bunch of stuff in a backlog right
so 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 for two years
right but 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 write an epic
engineer is more like a theme for that
collection of work right
the the agile team is working on making
some changes to how that works so that
it's a little bit more of a a
a bucket that truly contains tasks right
now it's more like a tag right so I have
some things in my own instance I have an
epical books to read
right so all of the books that i have on
my list have the books to read
epic right so at any any point in time I
can click books to read over here and it
will hide everything except that
so it gives me a a quick way to
visualize all the work of a cut a
certain theme
ok exactly like a tag yes exactly now
that's um so components are well the
first answer is it's called your agile
epics needs to be in there somewhere so
we call it that right
um structurally under the covers
it's not that different from components
right it's just another type of tag that
you can put on an issue that the biggest
difference is that with because it's an
epic you can click these filters and see
just the things for that particular
theme
ok so once you have a task and you put
them in epics then you start picking the
things that you want to do next
and you drag them up here to the next
sprint
so this is how prioritisation works in
scrum
so typically your backlog is a big long
list with hundreds of things in it right
putting that huge long list in order by
priority is generally not that effective
but picking the things that you want to
do in the next batch is really important
so grab the most important things put
them in the next print you can actually
start working ahead and bucketing your
stuff in advance so creating a new
sprint in this list is as easy as
clicking the create sprint button right
and giving it a name two weeks prince is
a pretty good standard usually one
week's print is too fast you're starting
and stopping Sprint's so often that the
administration is not worth it
so two weeks is a pretty good number
one month or six weeks is a little bit
too long too because what starts to
happen is if your sprint is six weeks
long and you get some new requests for
new work that has to be done right now
you're adding new stuff to your sprint
all the time so two weeks is a good
place to start and you may tweak that
yes um so deep so first you can link
tasks with together in jira so this
particular task here can be linked to
this other task right but this system
doesn't enforce that that other thing is
done first
like people have to self manage the
dependencies jira will indicate that
there is a dependency
but it doesn't help you make sure those
things are all done first before you
start for you
correct and actually also by dependency
I'll say jira allows you to link two
issues but jira doesn't know if you mean
this one has to be done first in this
one second
or vice versa right it just knows that
those two are related to be warm
right right ah let's see so I drag stuff
up on the other thing about two week
issue two weeks prints is that in a year
right there are 26 two weeks prints and
that's exactly how many letters of the
alphabet there are so it's really really
convenient for me to use letters for my
Sprint's right so that when we are
talking about which sprint we should do
things in everyone is on the same page
about whether we're talking about sprint
HR sprint I that's really handy if
you're thinking of names for your sprint
yes
um I generally create my ethics first so
i create my epic's first because that's
the thing that tells me what kind of
stuff I should be doing right so I know
I want to be so at work my epics or
something like you know do stuff to
support the experts do stuff for email
make changes to whack things like that
right so I make those first and then I
figure out ok we're going to do email
stuff
what what do we need to do for email
stuff next and that helps me the epic
first helps me figure out where to put
my energy
if i create tasks first right I'll think
of an infinite amount of things i want
to do to whack and we'll fill that will
fill my whole entire plate and I'll
never get to expert things right so I do
experts the first to make sure my work
is evenly balanced where I want it
ok ah let's see so once you start a
sprint you you click start spring by
clicking start at the bottom and I've
already started this one here and once
you have an active sprint you start
working in work mode so work mode looks
like this if columns right
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 decide hey I was working on
this but I actually stopped you can pull
it back over pretty intuitive
when you click the the project name you
will see the detail for that task in a
little pain that pops up over here on
the right
um and now the question that some people
have next once they start getting in
here as they say okay well to do in
progress and done
is nice but i have a review stage for
the work that i do right or I have you
know two teams that are working together
like a dev team and a QA team so I do
you know some work and then it pass it
over to the next guy and then he does
some work and they passes it back to me
um that's workflow inside of JIRA so you
can have this can work flow is
infinitely complex right we have a
customer in Massachusetts working
affiliated with MIT and they're doing
genetic testing using workflow they have
like literally eight thousand columns in
their workflow they can't display it in
a board like this but under the covers
they literally have 8000 steps for each
of the decoding genome prosper parts of
the process right so you can make this
as complex as you want
I will caution you however all the work
that you do should follow the same
workflow right so this is to do in
progress done because anything that I
could possibly imagine doing fits into
that workflow right
as soon as I have some things that say
like four books write books that might
be think of the book i want get it from
amazon read it
tell people about it right like that it
could be that but as soon as I have some
other things like watch some YouTube Ted
right then it doesn't fit into that
workflow and I need to manage two boards
and as soon as i have two boards and
four boards and six boards then there's
no one place I can go to look for all
the work that i have to do right
so don't get too crazy with how many
workflow steps you want
yes
all right so I my personal belief on
that is that's always two tasks right I
I i prepare the draft of the road trip
deck for jay wright and then I have a
second task that says you know
incorporate Jays feedback into the road
trip deck right that will always be two
tasks for me the waiting is right
because I I don't know how long the
waiting will be
i I can't work on the thing until i get
it back i'm not actually managing that
other person's time of waiting write the
review so like all those things really i
do the draft and then i have the the
accommodate the 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 so I
never have a waiting step but I mean
like with blogs here like we when we
manage our blogs in the HC j we do put a
review step in there so it's possible to
do it
I i typically don't because I'm not in
control of the people that i'm waiting
for
and my number one priority is I don't
want to have things in my in-progress
column that i'm not actually actively
working on
ok yes
this one shows students so realistically
have things like zero show or so there
are lots of some yes sir
red warm and right right so um so those
are so the do the you know prepare for
the road trip is a collection of tasks i
could give those a particular epic right
so like the epic that i use in in real
life is the you know are we have
atlassian events
I haven't lasting events epic and I have
a non-glossy and events epic right so
when I just when i click the atlassian
events
epic I'm going to see all of 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'm i haven't
started yet further down the list
I might start seeing summit tasks at
some point right but but they're really
in the same list and I should look at
them together usually if having them all
mixed together is confusing that I would
create two epochs to help me separate
those so in this particular view i'm
really only concerned about the things
I'm supposed to be doing by next Friday
and the things i'm actively doing right
now and then the other thing is at the
very top there's a quick filters so you
can see I can see only only my issues
are recently updated you can you can
create additional quick filters that
show you things of a particular type
right
yes absolutely
I'm almost always and actually what I'm
a tempting really is to make sure that
with each sprint
I'm advancing all of my epics a little
bit right in
in my particular context right in a
developer's world they might want to
focus on one epic knock it all the way
out and then move on to the next one
right but in in my my context
I'm trying to evenly distribute my work
across all the channels i need to
support right
ok so the next I'll talk about burned
down I think like burn down is really
probably the most important graph for
our thing people would would look at in
jira so burned down really
once you've once you've created a bunch
of tasks and you put them in a sprint
right and you've started that sprint
then your your goal is to take all those
things in that sprint and get them done
by the end of that sprint
so in our case a sprint is two weeks
right
and at the beginning of the sprint our
team collectively the four of us created
600 story points worth of work
ok so that's 600 story points worth the
work / 4 of us is telling us there's
about a hundred and fifty points each
that we're trying to do and I know from
our team's velocity that we generally
only do a hundred and twenty each so we
probably failed at the very first day
the sprint already right
and you can see that we're proving that
that's true because this line is our
actual progress and this line is what we
should be achieving right so in the next
two days we still have to finish 500
story points where the work and these
guys are screwing around here not doing
any work at all
so this is the brain down what you're
really looking for here is nice
even downgrade so that you're
accomplishing things over time
what you will see when you first start
doing this is you'll see a start and
then you'll see lots of up right and an
up line slope means you started your
sprint and then you added more things to
it right when you add more things to
your sprint your ability to finish what
you thought you were going to finish
starts going down so when you add
something to a sprint
ideally you should take something out
right because if you don't you're 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
home but that's what the upline means
right
the second thing that you're going to
see is you're going to see a bunch of
horizontal like this right and then
you're going to see that at one thirty
after these guys get out of this meeting
they're going to go back and close all
the tasks that they forgot to update
right and then i'm going to see a big
cliff right and that's and those are the
two things that you'll see and bring
down
um if you have the opportunity to
display this on a TV near your team and
make sure that everybody is is watching
this graph over time making it
it really helps make your team estimate
better it helps you figure out what
you're going to accomplish by the time
frame you think you're going to
accomplish it in and none of this is
about you know making promises to our in
our GM about what we're going to finish
right this is about getting better at
estimating what we think we're going to
accomplish right
the problems we have i think is we ask
me things that we can do this and then
it takes
right right
so to the two things about that first
that happens to everybody right when
there's when they start estimating at
first like in your past you've probably
never ever had to estimate the things
that you did
so you're you probably suck an estimated
first
that's why story points is more useful
than ours
right because it doesn't matter if you
think a story . it is our that for story
points is two hours
what really matters is that you finish
50-story points a week right
whether whether you think that's you
know a hundred hours or or 40 hours
doesn't matter you can look at this
graph over time after your sprints and
we can see
okay wait you guys are only doing 50
points each
you think you're going to do 80 points
each
so each time you start a new sprint you
should lower the number that you're
starting with e it doesn't actually
matter if you 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've delivered in the past right
correct and so so that that variability
is is always part of this definitely
what what's generally true is that the
amount of easy things than the amount of
hard things in your plate is on your
plate is fairly consistent over time
right
you know that little waffle back and
forth but when you after you do you know
a year's worth of sprint estimation
when you look back at a year and see
that your average velocity velocity is
the number of story points you can do in
a sprint right after looking at it for a
year you'll be able to see pretty
clearly that you get about the same
number of points on every time
yes got because you know that a
everything when we get that there's not
a way to do that here
although you can clone an issue but
that's finding the old issue to clone is
probably more effort than than it's
worth
generally what happens is people over
time start to say ok when I do a blog
that's probably realistically 16 points
right and they just know that that and
you just start remain you just get
better
yeah
right
um so those are those happen for sure
right and so the reason that the reason
that i only get you know a hundred story
points done in two weeks is because you
know i'm doing a lot of other stuff
besides the stuff that's on this list
and so those interruptions when they're
when they're consistent over time those
interruptions will be truly reflected in
your velocity right
what's bad is when you know over a
course of a month right before summit
right people go up to Rudy like every
four minutes right and ask him questions
but then like three weeks after summit
is over right he goes through a period
where he's in more control of his time
right
and so Rudy's ability to estimate his
interruptions is is hard right and a lot
of us have those same sort of roller
coaster interruption patterns but really
there's nothing in g.r that will help
you manage that
jira and most agile trackers are
assuming that whatever the variables are
in your work day whether it's easy stuff
to estimate and hard stuff to estimate
easy things to do and hard stuff to do
interruptions the time of day you work
how many weekends you like most agile
trackers are assuming that all of those
variables are just constant across the
year worth of time right
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 right
so that when you're planning your
upcoming things look at how much you
accomplished in the past and try to try
to plan according to those things right
so the next thing I was going to show
you is your issues and dashboards so
once you have work in jira looking at
that work in dashboards is
aside from the work that you're actually
doing so day-to-day you
usually looking at work mode right
you're looking at the task you're trying
to do you're moving the tasks closer to
done if you're can if you're interested
in what your team activity is if you're
interested in the work other people are
doing . dashboards helps you do that
right
this is a basic your jet 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
on the this is my home one again
and so you can see this is sort of
focused on things I'm doing for home
things I'm doing for work and then quick
access to the to the lists that I go too
often
if what you're looking for isn't there
what you'll generally want to rely on
next is searching for issues
so if you click the issues we 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 if you
click that once you click search for
issues then you end up with a screen
that looks like this right
there's 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
end up with drop down boxes here at the
top you just pick a project you pick
status and you can pick just by checking
check boxes
there's also more link somewhere over
there and when you click more everything
that's in your jira instance is a choice
right so if it was on the create issue
screen as something you can put in then
it will be in that filter drop-down box
so creating a collection of issues to
look at is is pretty easy with basic
search as you get more complex
you'll want to maybe switch to what we
call j ql so j ql in our vocabulary is
jira query language and 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 type of project i got
list that look like this and I could
pick equals from it and then as soon as
i hit space after equals it gave me a
list of the projects that were choices
right and so you can sort of start
typing and it will suggest whatever your
possible choices are so it's really
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
everything that lots of people are doing
you can just look at your stuff I could
just look at Jake stuff like whatever
whatever you want and so this is how
search works
so all the gadgets on the dashboard use
search all of the quick filters on your
agile boards use search
so go to issues and search for issues
and play around with that search
mechanism a little bit because you'll
see when you go to try to do other
things on work boards or with workflow
you'll see that those that you'll need
to know how to do j ql either in basic
for more advanced and that's searching
that's work mode that's Plan mode that's
creating issues that's pretty much it
but now i can do questions as many as
you want that's a great question
so I we last May we released the html5
version of your mobile
so there's no app it's just it just
works in a browser on your phone so if
you go to EA CJ on your phone and login
just like you would at your desk
you will get a simplified version of the
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 what's in
progress what's important what's
critical and then the second thing that
it's designed for is when you're at
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 that thing that
you got when you click the link in email
was readable
that's it's real job that's it yes
yes
yeah yeah for sure um in the beginning
of februari or late January confluence
52 came out 54 right so there was a
project which we codenamed coat hanger
right and 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 and
it's pretty cool so
oh the did the design and this is pretty
important from a and lassie and
messaging perspective right
our design is that a team will
collaborate on requirements together as
a team in confluence right they'll take
an idea and turn it into something that
has flushed out specifics at some point
in that process that list of
requirements turns into a list of things
you want to do and so in confluence you
end up with the list
you suck that list in de gira
automatically it creates the list of
things inside an epic right in JIRA and
then you assign that work in JIRA and
then using the create branch link inside
of JIRA you can immediately create link
to the source code right to the issues
in giro which are linked to the
requirements document in confluence so
end-to-end from concept to launch with
very few clicks those integrations work
so alright uh that's that's it but like
as you guys get started and start
playing around
definitely come find me if you have any
questions and that's it
thanks for coming
ok