►
From YouTube: Value Stream Management Dry Run
Description
Value Stream Management Dry Run
A
Thanks
melissa,
it
is
now
my
turn
to
showcase
a
demo
on
how
we
do
value
stream
analytics
at
kit.
Lab
first
thing:
I'm
gonna
start
off
with
is
showing
how
we
do
some
structuring
with
someone
that
might
use
gitlab
organizations
and
and
how
they
build
out
their
groups
within
the
gitlab
tool
and
itself
how
we
do
it
as
well
at
gitlab,
and
when
we
look
at
this,
we
have
starting
from
left
to
right
the
wake
and
organizes
via
groups,
subgroups
and
projects.
So
a
group
can
be
at
the
parent
level.
A
Let's
say
gitlab.org,
which
is
our
development
group.
Is
that
top
level
group-
and
there
are
subgroups
underneath
that
maybe
the
plan
team,
the
verified
team,
those
fall
underneath
and
subgroups
that
all
roll
up
to
the
parent
gitlab.org
group,
and
then
you
have
the
projects
that
are
specific
to
those
teams,
is
where
the
code
repositories
kind
of
live.
It's
where
a
lot
of
the
issue,
user
story
management's
going
to
be
done
and
looking
at
that
work
breakdown
when
we
look
at
the
group
levels
is
where
epics
are
created.
A
Those
large
ideas
are
built
out
on
the
vision
for
that
group,
and
you
have
the
capability
to
align
the
child,
epic.
That
may
be
specific
to
a
subgroup
so
specific
to
the
planned
team,
the
certified
team
they
have
their
child
epics
that
are
their
large
ideas
within
their
group
that
will
align
to
that
gitlab.org,
epic,
maybe
it's
you
know
something
that
is
a
a
portfolio,
epic,
a
value
stream
of
some
sort,
and
then
you
have
the
issues
at
the
project
level.
A
This
is
where
the
issues
will
be
directly
correlated
to
that
merge,
request
to
that
change,
that's
being
added
or
corrected.
That's
that
user
story
issue
that
lives
at
that
project
level.
That's
where
the
team's
going
to
do
a
lot
of
their
sprint
planning
and
organizing
on
a
team
level
and
the
subgroup
level
is
where
that
group's
going
to
do
their
organizing
for
all
the
teams
that
fall
underneath
it
on
the
right.
We
see
the
tracking
capabilities
gitlab.
A
Gitlab
has
a
two
different
things
called
iteration
and
milestones.
The
lab
originally
came
out
with
iterations
as
a
time
box
a
way
to
define
your
time
box
period.
So
this
is
what
was
used
to
define
sprints
or
releases,
and
since
then,
what
we've
created
is
milestones.
So
you
can
use
those
iterations
to
maybe
define
a
release,
a
quarterly
release
of
monthly
release
and
that
will
align
to
that
group
or
that
subgroup
level,
and
then
you
have
milestones,
which
are
more
specific.
A
A
Now
I'm
going
to
go
into
the
demo
itself,
the
demo
environment
itself
and
we're
going
to
start,
I
guess
with
an
understanding
of
how
gitlab
is
mapped.
Let's
move
to
how
value
is
defined
and
tracked
with
gitlab,
so
gitlab
value
stream
management
focuses
on
increasing
the
flow
of
business
value
from
customer
requests
to
customer
delivery.
A
A
The
seven
base
stages
in
this
case
that
are
considered
as
sample
process
flow
or,
actually
you
know,
default
first,
one.
That's
using
value
stream
analytics
come
across
as
you
have
issue
plan
code,
test
review
and
staging
and
qa
is
just
in
here,
looks
like
we
so
added
that
an
example:
let's
go
to
default
only
vsa,
and
now
we
see
that
the
default
stages
are
present,
so
tracking
is
built
into
gitlab
and
collecting
and
showing
data
from
across
the
software
development
lifecycle.
A
A
A
A
So
let's
take
a
look
at
issue
here.
It's
created
at
9
00
am
this
is
the
start
of
the
issue
issue
stage
and
then
an
issue
is
added
to
a
milestone
at
a
11.
Am
so
that's
now
the
stop
of
the
issue
stage
and
the
start
of
the
plan
stage
so
start
working
on
the
developer
starts
working
on
the
issue,
creates
a
branch
locally
and
makes
one
commit
at
noon.
A
Make
a
second
commit
to
the
branch
that
mentions
the
issue
number
at
12,
30
pm
and
that's
the
stop
of
the
plan
stage
and
now
the
start
of
the
code
stage
push
a
branch
and
create
a
merge
request
that
contains
the
issue,
closing
pattern
so
merge
request.
That
has
a
pattern
that
will
close
the
issue
in
its
description
at
2
pm,
and
this
is
the
stop
of
the
code
stage
in
the
start
of
the
test
and
review
stage.
A
Next,
the
merge
request
is
merged
and
a
deployment
to
the
production
environment
starts
and
finishes
at
7
30
pm.
So
this
is
now
the
stop
of
the
staging
stage.
So
from
the
previous
example,
we
see
that
the
time
used
for
each
stage
is
the
issue
took
two
hours
from
nine
a.m:
to
11
a.m.
Plan
took
one
hour
from
11
a.m,
to
12
p.m,
and
then
code
took
two
hours
from
two
to
four
pm.
A
So
that's
just
a
sample
flow
example
flow
of
how
this
might
be
used
and
if
we
look
at
some
of
the
the
metrics
we
can
pull
from
as
a
flows
like
this
that
we've
built
up
for
our
teams.
We
can
look
at
a
lead
time,
which
is.
This
is
a
medium
time
from
that
issue
created
to
that
issue
being
closed.
So
currently,
if
we
look
at
the
you
know
default
vsa
here
we
see
it's
about
two
weeks
from
the
issue
being
created
to
be
closed.
A
A
Being
closed,
and
so
we
may
look
at
lead
time
as
an
issues
created
and
this
cycle
time
is
only
around
one
day,
so
in
particular
we
may
look
at
that,
but
the
issues
created
and
it's
picked
up
13
days
later
and
then
that
first
merge
request
is
made
and
then
over
the
course
of
that
day
it
moves
to
the
different
stages
and
then
it's
merged
and
pushed
out
to
production.
So
it's
less
than
one
day
cycle
time
from
the
beginning
of
that.
First
merge
request
to
the
issue
being
closed.
A
When
we
look
at
deployment
frequency,
this
is
something
that
is
in
line
with
door
metrics,
it's
a
one
of
the
four
that
we
currently
have
on
the
value
stream
analytics,
there's
a
second
one
that
will
be
coming
soon
and
that
second
one
is
the
lead
time
and
that
metric
will
still
be
shown
here
on
value
stream
analytics.
Now,
let's
show
you
how
someone
can
create
a
value
stream,
workflow,
that's
aligned
to
their
organization.
What
we
can
do
is
go
into
here.
A
A
A
You
have
a
select
a
start
event,
so
we
have
over
100
different
combinations
of
start
events
that
you
can
use
for
your
organization
by
choosing
one
of
those
that
gives
you
an
end
event
that
aligns
with
that
start
event,
and
this
is
adjusted
depending
on
you
know
the
different
start,
events
that
you
have
and
those
will
be
closely
aligned.
If
we
don't
want
to
use
the
the
the
default
value
stream,
we
can
go
create
from
node
template,
and
this
is
where
we
can
have
another
stage
that
we
create
from
scratch.
A
A
I
click
on
solution,
validation,
it's
going
to
give
me
a
running
list
of
the
issues
that
are
correlated
with
solution,
validation,
they're
in
that
stage
now,
and
if
I
want
to
take
a
look
at
hey.
What's
what's
been
in
this
stage,
the
longest
amount
of
time
I
can
do
that
here
I
can
dive
into
that
issue.
A
I
can
see
that
you
know
here's
a
description.
This
is
the
issue's
been
built
out
and
then
there's
been
some
collaboration.
That's
been
happening
around
it
and
I
can
read
into
that.
If
I
want
to
see
where
are
they
at
maybe
they're
stuck
somewhere?
What
decision
has
it
been
made?
You
can
see
that
there's
a
lot
of
coordination
around
setting
the
appropriate
labels.
They
have
the
milestone.
The
next
release.
14.2,
that's
expected
and
I
can
go
in
and
if
any
problem
solving
needs
to
be
happen,
I
could
do
so
there.
A
If
not,
I
could
just
understand
better
why
it's
taken
three
days
to
it's.
The
amount
of
time
spent.
It's
been
13
days
in
this
particular
stage,
going
back
to
the
overview
view.
I
also
have
a
couple
different
things
that
a
couple
different
graphs
that
I
can
see
here
days
to
completion.
So
this
is
the
average
time
spent
in
the
selected
stage
for
the
items
that
were
completed
on
each
date
limited
to
the
last
500
items.
I
can
organize
this
by
stages.
A
If
I
only
want
to
see
a
particular
stage,
I
can
do
so
here
or
group
of
particular
stages.
I
can
do
that.
Otherwise,
I
have
a
graph
here
that
is
going
to
identify
average
data
completion
based
on
that
time
frame
time
frames
can
be
adjusted
up
here
right
now,
I'm
looking
at
the
last
month.
If
I
want
to
do
a
comparison
of
maybe
the
month
before
that,
we'll
click
on
this,
we
can
see
that
the
certain
amount
days
are
selected.
That's
65
days.
Let's
just
move
this
back
to
hey.
A
So
task
by
type
in
order
to
become
efficient,
we
need
to
understand
what
type
of
work
our
team
does,
how
much
of
it
and
how
quickly
it
goes
through.
So
pms
have
difficult
time
to
optimize
between
features
bugs
technical
debt
and
security
issues
and
usually
there's
no
easy
way
to
communicate
trade-offs
to
management
and,
moreover,
they
don't
know
how
much
of
that
work
is
stuck
in
each
stage,
and
so
this
gives
us
visibility
into
that
date
and
the
type
of
task
that
is
being
worked
on.
A
Maybe
it
is
a
back
end
issue
or
a
qa
issue.
I
can
have
visibility
into
the
quantity
and
frequency
based
on
that
day
and
how
many
are
in
progress
on
that
current
day
and
gives
me
kind
of
a
trend
graph
over
time
to
understand
those
different
specific
labels
that
associate
with
with.
However,
we
decided
to
organize
our
group.
A
So
earlier
I
quickly
went
over
there,
but
I
just
kind
of
want
to
reference
it
here
we
have
this
cicd
section.
This
is
something
where
aligned
with
our
value
stream,
building
out
door
metrics.
We
have
deployment
frequency
that
is
available
here.
This
shows
us
a
trend
graph
of
the
number
of
deployments
over
a
certain
amount
of
time,
and
we
can
look
at
the
last
week
month
and
last
90
days
and
then
as
well.
We
can
see
that
lead
time
with
those
similar
time
frames.
A
If
I
go
back
to
the
value
stream,
this
is
just
showing
that
currently
we
have
the
deployment
frequency
coming
in
through
as
a
metric
right
here
and
soon
that
lead
time
will
also
be
coming
through
as
a
a
metric
as
well
and
to
wrap
up
this
value
stream
a
quick
overview
demo
overview
here.
I
want
to
go
into
devops
adoption,
devop
adoption.
A
This
is
something
which
groups
in
your
organization
are
you,
it
kind
of
showcases
which
groups
in
your
organization
are
using
the
most
essential
features
of
gitlab,
and
so
it's
broken
down
with
an
overview
and
also
obviously
just
kind
of
showing
the
different
stages.
So
you
have
dev
sec
and
ops
here.
This
is
an
overview
showing
everything
that's
been
adopted.
A
But
if
I
go
into
dev
it's
going
to
break
that
down
by
a
group,
it's
going
to
show
approvals,
code
owners
issues
and
merge
requests
who's
using
them
and
what
groups
are
using
them
same
thing
with
second
ops.
I
can
see
das
sas
and
scanning
and
then
off
system
to
give
me
deployments
pipelines
and
runners,
and
so,
if
I
want
to
see
in
this
case
which
of
my
groups,
those
subgroups
that
roll
up
to
gitlab.org
are
using
these
particular
capabilities
of
the
gitlab
product,
I
could
take
a
look
at
that.