►
From YouTube: GitLab Plan and Boards Usage
Description
Melissa Ushakov and Viktor Nagy walk through how he uses boards as part of milestone planning and issues refinement.
A
B
B
So
what
we
have
in
this
shoe
is
a
link
to
the
playing
board.
What
I
do
here
on
a
monthly
basis,
I
have
to
update
the
label
to
match
the
next
candidate
one.
I
started
to
think
about
that.
Okay,
I
might
assign
issues
to
milestones
in
the
future
and
then
just
use
that
instead
of
a
candidate
label,
the
issue
with
that
would
be
that
then,
once
the
milestone
starts,
every
issue
is
active,
even
though
I
don't
want
that.
So
that's
that's.
B
Where
will
it
appear
now?
Okay,
okay,
we
don't
have
anything
deliverable
yet
because
it's
a
planning
board
but
like
I
have
no
idea
where
we
are
ready
for
development.
It
will
just
appear
somewhere
in
that
column
might
be
the
first,
but
actually
I
prioritize
this
column.
I
know
that
this
should
be
the
first
item
and
then
changing
something
on
a
separate
screen,
actually
just
messes
up
my
prioritization
immediately.
A
A
B
That's
that's
not
really
annoying,
because
what
my
the
use
case
here
wouldn't
be
that
I'm
not
starting
from
board,
but
I'm
starting
from
anywhere
else.
So
we
are.
We
are
just
discussing
this
issue.
This
is
where
I'm
at
and-
and
I'm
not
even
thinking
about
the
board-
I'm
not
even
thinking
that
this
will
mess
up
my
prioritization,
and
that
is
the
issue,
because
if
I
am
here-
and
I
know
that
okay,
I
want
to
make
it
deliverable-
I
just
move
it
to
the
right
spot.
C
B
B
It's
not
even
that
because
seriously
like
just
imagine
that,
like
on
slack
support
sends
you
an
issue
that
or
whatever
and
as
it
okay,
you
know
that
that
was
paradise
for
a
long
time
with
its
reach.
Finally,
the
milestone
you,
you
start
discussing
it
on.
On
slack
with
the
team.
Everything
everybody's
agreed
that
actually
it's
well
refined.
It
could
actually
even
be
accepted
as
deliverable,
so
somebody
from
slack
opens
its
issue
and
as
a
deliverable
label,.
A
B
B
And
that's
that's
why
what
I
did
just
last
month.
Initially
this
was
an
open
column,
and
now
you
can
say
this
is
actually
the
group
configure
column
and
the
whole
board
is
filtered
for
the
configure
label.
So
all
the
issues
appear
here.
Everything
that
was
on
the
board
is
on
the
first
column
as
well,
and
this
way
I
know
the
prioritization
relatively
quickly,
but
it's
it's
already.
It
took
us
a
long
time
to
to
figure
this
trick,
because
initially
this
was
an
open
currency.
A
B
Idea
would
be
that
when
somebody
applies
a
label
it,
it
should
either
become
the
first
or
the
last
item
in
the
column,
depending
whether
I
move
it
to
the
left
or
the
right
on
the
board.
So
it's
that's.
I
told
you
this
whole
story.
Of
course
this
is
what
you
should
cut
off
once
it
goes
to
development,
but
I
told
you
my
wishes
so
because
when
I,
when
I
move
it
forward,
I
want
it
to
be
the
last
item,
but
when
I
move
it
backwards,
it
should
be
the
first.
If
I
like.
B
A
B
B
So
I
I,
if
everything
works,
fine,
then
just
having
an
open
column
here
is
perfect,
because
what
I'm
really
needing
is
okay,
like
these
are
deliverables.
These
are
good
for
development.
That's
fine!
I
don't
need
the
overall
view.
Okay,
sometimes
okay,
let's
speak
about
the
the
the
management
of
this
board
first.
B
So
what
is
extremely
annoying-
and
I
think
I
spend
way
more
time
on
it
than
than
not
not
this
way,
because
that's
the
best
way
I
have
today,
but
what
I
would
love
to
spend
is
moving
issues
around
so
like,
let's
move
this
last
item
back
to
the
somewhere
to
top,
sometimes
this
calling
works.
Sometimes
it
doesn't.
B
C
B
B
A
B
I,
like
I'm,
not
thinking
about,
I
don't
want
it
to
have
any
other
state.
I
wanted
to
prioritize
within
this
column
and
what
I
have
to
do
is
to
move
it
somewhere
else
get
back
here.
So
it's.
I
often
don't
don't
get
this
idea
and
I'm
just
yelling
at
the
screen
that
this
color
doesn't
work
or
why
I
don't
have
no.
A
A
B
B
That
is
when
I
move
issues
between
these
columns,
especially
for
example.
Here
I
am
ready
for
development,
and
the
team
agrees
that
this
should
be
deliverable.
So
let
me
move
it
to
deliverable
and
now
what
happened
is
that
it's
not
really
for
development
anymore
and
of
course
I
understand
the
logic
what
we
have
today,
but
this
is
not
what
my
intention
was.
My
intention
was
to
add
the
deliverable
label
as
well
in
this
situation,
and
I
have
no
idea
how
to
do
it
on
this
board.
B
B
When
it's
called,
of
course,
it
will
remove
one
scope
and
add
the
next,
so
that's
that
that's
totally
exactly
what
I,
what
I
would
expect
and
what
I
run
into
lately,
is
that
I
would
love
to
add
more
filters
here
because,
like
what,
if
I
want
this
column
to
be
group
configured,
that's
fine,
but
even
for
a
minute.
Let's,
let's
exclude
everything,
that's
ready
for
development,
because
I'm
really
looking
in
prioritizing
the
the
planning.
So
what
needs
refinement-
and
this
happened
just
today.
B
What
I
had
to
do
is
that
I
excluded
the
ready
for
development
label
from
the
whole
board,
and
then
I
I
had
a
shorter
one
here.
So
I
would
say
these
are
the
primary
things
that
I
that
I
struggle
with
and,
of
course
that
could
be
a
huge
amount
of
automation
like
oh
yeah,
one
automation.
That
really
means
is
that
actually,
the
whole
team
works
out
of
two
boards.
That's.
B
Yes,
and
what
would
be
really
nice
is
to
be
able
to
move
from
this
one
to
the
next
keeping
the
prioritization,
because
what
I've
learned
two
months
ago,
that
every
board
has
its
own
privatization
of
issues,
which
means
that
we
set
everything
up.
We
plan
everything.
Fine
deliverables
are
in
privacy
order
and
then
the
milestone
starts
and
our
billboard
has
a
different
ordering
of
the
of
the
same
issues
totally
unexpected.
Actually
so,.
A
B
A
B
A
B
A
B
Yeah
yeah-
and
this
is
this-
is
our
setup
today,
so
I
can
easily
imagine
that
that
you
would
have
different
recommendations
how
to
use
these
boards.
We
are
really
happy
to
have
fixed
boards
for
planning
and
for
for
for
the
build,
because
this
way,
as
you
can
see,
I
actually
have
a
shortcut
here
that
just
opens,
if
I
don't
miss
type.
B
Yeah
and
it's
always
the
same
link,
so
that's
that's
why
it's
great
and
that's
why
I
was
thinking
like
okay.
This
is
the
planning
board
once
the
planning
is
over.
Let's
just
switch
the
board
setup
itself
so
that
this
will
be
the
billboard
for
that
milestone.
But
then
I
need
a
new
link,
a
new
board
for
the
next
milestone,
and
it's
it's
just
easier
to
say
that
we
have
a
board:
that's
planning
a
board,
that's
built
instead
of
a
board
for
14.9
board
for
14.10.
That
would
be
the
alternative
that
I
see.
A
Yeah,
because
I'm
thinking
about
the
jira
experience-
and
they
just
have
basically
like
a
list
like
view-
that's
kind
of
segmented
by
sprint
and
that's
how
they
do
it
instead
of
having
two
different
views,
but
I
actually
like
having
the
two
separate
views
personally
like
as
a
user
okay.
So
it
allows
you
to
do
like
the
dual
track:
type
of
workflow,
which
is
nice
yeah,.
B
B
A
Yeah
you're
doing
two
different
things
and
two
different
boards,
but
one
thing
that
I
think
would
be
a
nice
because
that
that
is
similar
to
what
I've
seen
with
a
lot
of
gitlab
pms.
It
would
be
nice
to
have
some
sort
of
board
auto-generated
if
there's
a
milestone
coming
up
or
something
like
that
right
with
all
the
right
filters
and
then
once
it's
done,
maybe
it
like
gets
removed
somehow,
but
that
would
be
a
nice
quality
of
life
thing.
B
Yeah-
I
was
thinking
about
this
because
I
think
that
just
now
there
is
a
terraform
resource
for
boards
and
and
we
manage
the
the
traffic
provider.
So
that's.
Why
I'm
aware
of
that?
So
I
in
principle
I
should
be
able
to
manage
the
board
with
terraform,
but
the
real
question
is
that
once
I
move
from
the
planning
to
the
build
stage,
how
can
I
do
that
easily?
B
A
B
Yeah,
but
then
then
comes
the
issue
that
what
I
said
before
that
there
are
the
issues
that
I
don't
want
to
be
added
for
the
14.9
execution,
so
those
should
be
left
off,
which
actually
could
be
just
a
set
of
filters.
So
it
could
just
say
that
only
ready
for
development
and
every
other
workflow
label
that
that
comes
after
that
is
included
in
the
in
the
filter.
But
today
such
filters
are
not
an
option.
B
The
workflow
labels
like
here
what
I
have
refinement
and
ready
for
development,
and
this
is
what
the
whole
board
should
be
filtered
on,
and
then
I
have
another
board
which
says
that
give
me
actually
the
same
board
except
the
theater
should
be
ready
for
development
in
dev,
in
review,
etc.
So,
and
and
kind
of
this
would
be
one
so
like
like
one
idea
would
be
to
have
a
proper
query
language
and
the
other
is
to
clone
the
board,
which
would
mean
that
it's
the
exact
same
board,
the
prioritizations
are
the
same.
A
Yeah,
there's
some
thinking
going
around
around
for
like
more
of
a
proper
query,
language
and
more
of
like
saving
queries
right
and
like
rendering
different
views
of
that
same
like
like
statement
right,
whether
it's
in
a
board
view
or
list
view
or
like
a
roadmap
view
or
so
yeah.
We've
been
thinking
about
that
a
lot
too,
but
just
to
wrap
this
up
and
and
going
back
to
the
thanks.
It
was
good.
A
B
B
B
A
B
B
What
now,
as
I
said,
that
I
can
imagine
that
we
could
change
our
setup
if
there
would
be
like
another
option,
would
be
that
I
create
a
bitly
link
that
and
I
have
a
board
by
milestone,
and
I
just
have
a
bitly
that
I
change
month
after
month
to
redirect
the
to
the
current
milestone
and
then
I
can
still
have
the
the
static
link
and
because
then
it's
it's
the
same
board.
So
I
can,
I
kind
of
save
the
issue
showed
moving
between
boards.
A
The
problem
becomes
like
how
do
we
properly
scope?
It
we've
been
talking
a
lot
about
like
having
an
automation
engine
where,
like
people
could
define
those
rules
right
like
create
a
label
create
a
board
for
every
like
group,
is
what
our
logic
would
be
right,
like
for.
Every
scope
in
a
group
create
a
board
for
the
upcoming
milestone,
and
this
milestone.