►
Description
This video is Project Management How to Part 2 of 3
Part 1: https://www.youtube.com/watch?v=9W4oxjdAwUs
Part 3: https://www.youtube.com/watch?v=J2u7OqBA_aQ
GitLab Handbook for the Marketing Department's guidelines for using GitLab project management: https://about.gitlab.com/handbook/marketing/project-management-guidelines/
A
Oh
hello,
this
is
William,
I
am
part
of
the
product,
marketing
team,
Eket
lab
and
in
this
video
I
want
to
talk
about
burndown
charts.
So
in
my
previous
video
I
talked
about
how
to
use
issues
Epic's
milestones
and
roadmaps,
while
I
was
talking
about
milestones,
I
forgot
to
talk
about
the
burndown
chart,
so
this
is
a
video
just
to
talk
a
little
bit
about
that.
A
So,
if
we
look
here
at
a
milestone,
if
you
want
to
know
about
that
check
out
the
previous
video,
but
we
know
that
a
milestone
is
a
particular
period
in
time.
Let's
say
these
next
two
weeks,
what
am
I
going
to
get
done
between
June
15th
and
June
28th,
whatever
I
think
I
can
get
done
in
that
time
period.
When
I'm
planning
out
my
work,
I
add
issues
to
that
milestone.
A
You
know
my
team
might
add
all
of
their
team
issues
to
this
mouse-over,
which
is
actually
how
this
one
works,
and
then
we
have
this
chart.
So
when
I'm,
looking
at
a
specific
milestone,
this
chart
is
going
to
show
me
how
many
issues
are
in
that
milestone
and
what's
our
progress?
Look
like
so.
For
example,
here
we
started
on
June
15th.
We
thought
there
are
22
things
we
can
get
done.
A
So
we
put
22
issues
into
this
milestone
in
the
next
two
weeks
and
then,
as
we
got
stuff
done,
you
can
see
the
timeframe
in
which
things
were
closed,
and
so
here
we
still
have
15
things
left
to
do
and
the
next
two
days
so
I'm.
Not
it
there's
a
couple
things
going
on
here:
either
people
have
gotten
stuff
done
and
they
haven't
marked
it,
which
is
you
know,
no
good.
If
you
mark
it
done
that
way,
you
get
some
visibility
or
there
are
some
things
that
are
gonna
slip
into
the
next
milestone.
A
So
these
15
things
don't
get
done
by
Friday
tomorrow,
then
we'll
move
them
into
the
next
two
weeks,
which
is
the
next
milestone,
but
that's
what
this
burndown
chart
is
showing
is
showing
you.
The
progress
of
how
things
are
closing
I
can
see,
for
example,
within
this
milestone
the
people
that
are
participating
in
it.
This
is
my
team.
All
of
these
people
have
issues
that
they
are
assigned
within
this
milestone.
I
can
see
the
set
of
labels
all
of
the
issues
that
are
part
of
this
mile.
A
What
labels
are
they
categorized
with
I
can
say:
there's
no
merge
request.
If
there
were,
they
were
part
of
this
milestone,
and
here
are
the
issues
and
I
can
see.
If
there
are
any
unstarted
issues
mean
there's
an
open
issue,
it's
a
sign
of
the
milestone,
but
nobody
is
assigned
to
it
yet
that
we,
you
know,
nobody
is
nobody's.
Gonna
start
this
issue
once
somebody
is
once
it's
open
and
it
has
an
owner.
So,
for
example,
this
kickoff
kick
off
the
market
requirements.
It's
opened,
it's
part
of
the
Bangalore
milestone
and
it's
assigned
to
me.
A
So
this
is
one
that
I'm
working
on
and
here
it
shows
as
open
and
started
and
then
if
it
gets
closed,
so,
for
example,
this
roadmap
issue.
This
is
a
completed
issue.
We
can
see
that
it
was
open.
It's
part
of
the
Bangalore
milestone,
which
is
this
two
weeks
and
it's
closed
Jordie
was
assigned.
He
did
the
work,
he's
completed
it
and
it
shows
us
closed
and
that's
one
of
these
issues
that's
been
closed.
So
this
is
the
milestone
view
within
gitlab.
This
is
what
the
burndown
chart
is.
I,
don't
use
this
one,
a
ton.
A
This
is
more
like
if
you're
managing
an
entire
team
or
entire
project,
with
a
lot
of
different
people
and
you're
trying
to
see
a
sense
of
the
work.
That's
what
this
view
is
for,
but
for
most
parts,
if
you
have
an
issue
and
you're
assigned
an
issue,
it'll
show
up
here,
so
I'll
probably
do
one
more
video
where
we
talk
a
little
bit
about
issues
and
boards,
but
just
wanted
to
give
you
this
quick
view
of
the
milestone
view
with
the
burndown
chart.