►
From YouTube: Value stream events and custom workflows
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
we're
recording
so
we're
talking
about
value
stream
management
again,
so
we
talked
about
this
a
couple
of
maybe
like
I'm,
almost
3-4
weeks
now,
I
think
three
weeks
ago
and
I
wanted
to
share
something
latest
thinking
that
I've
had
with
value
stream.
Mapping
about
I
mean
it's
called.
A
lot
of
things
are
extreme
asking
about
stream
management
in
support,
and
so,
if
you
look
at
the
issue
that
I
linked
into
agenda
you'll
have
some
ideas
there.
So
I
share
my
screen
in
particular,
and.
A
The
the
high
level
concept
is
still
very
similar
where
you
want
to
have
some
concept
of
time
or
cycle
time,
and
even
yesterday,
when
I
was
talking
some
other
folks,
maybe
we
don't
even
have
to
just
use
as
a
first
release.
We
don't
have
to
say
cycle
time.
We
just
say
whatever
it
is,
whether
we're
whatever
you
were
like,
if
we're
using
stages
or
labels
or
whatever
we
could
just
use
that
term
directly.
A
But
what
I
wanted
to
emphasize
is
that
what
we
talked
about
last
time
is
that
we
talked
a
lot
about
using
stages
and
and
using
figuring
out
what
are
the
custom,
workflow
stages
and
then
building
downstream
analytics
on
top
of
that
or
balance
tree
management.
And
then
a
different
approach.
I
wanted
to
consider
is
using
events
instead
of
using
stages,
and
the
reason
I
wanted
to
consider
using
events
is
that
events
are
more
flexible,
I
think
and
it
doesn't
prevent
us
from
using
stages.
A
So
I'll
quickly
go
over
what
my
concept
is
here
and
then
maybe,
let's
just
have
a
more
of
a
for
your
discussion
so
and
my
concept
I
mean
I,
won't
go
over
to
concept.
I'll
just
go
over
the
really
quick
designs
that
I
have
and
then
and
then
we'll
go
from
there.
So
the
what
I
have
here
is
that
we
do
use
labels
now
and
then
so
so
we'll
go
back
and
talk
about
that.
A
Like
I
thought,
we
said
that
we
didn't
want
to
use
labels,
but
what
I'm
proposing
here
as
a
first
iteration
is
that
we
do
use
labels
and
say
likes
started
and
then
going
to
complete,
but
we're
not
saying
that
these
are
stages
necessarily
or
we
don't
really
care
about
that.
Like
there's,
no
concept
of
an
issue
board
here
notice,
it's
just
you're
configuring.
The
fact
that
every
time
your
issue
has
applied
started
or
every
time
you
issue
is
applied
complete.
A
These
are
two
events
and
then
find
the
the
time
between
them,
because
you
can
know
the
time
stamps
of
those
events.
And
then
that
is.
That
is
the
time
that
we
care
about,
and
you
can
take
that
rigid
so
and
so
forth,
and
then
once
you
have
that
because
it's
events,
then
you
can
add
multiple
events
right.
So
you
have
the
start
event
the
complete
event.
Then
you
can
have
additional
labeling
events
and
then
once
you
have
that,
then
you
can
have
the
times
in
between
them.
A
You
can
have
the
times
from
this
one
to
this
one
and
so
on
and
so
forth.
So
you
can
do
some
additional
fancy
things
and
then
once
you
have
that,
then
you
can
add
additional
events,
so
it
doesn't
even
have
to
be
label
events
anymore
right.
It
could
be
an
event
that
you
care
about
that.
You
tell
Gil
out
that
an
issue
was
closed
or
open
merger
crisis
associated
with
the
issue.
A
This
there's
a
pipeline
and
then
maybe,
if
we
event
stages,
we
could
say
that
an
issue
entered
a
stage
or
exited
a
stage
and
so
on
so
forth.
So
these
are
all
events,
and
once
you
have
an
events
then
can
plot
the
times
between
the
events.
What's
also
interesting
is
that
once
you
have
events,
then
you
can
do
something
fancy
like
this,
where
you
can
say
all
the
times
that
that
issue
went
into
in
review.
What
is
the
time
there?
A
When
is
all
the
time
that
issue
entered
the
complete
event
or
not
entered
but
was
associated
with
the
complete
event,
and
then
you
can
see
from
statistically
how
that
spread
is
and
then,
more
importantly,
these
events
can
be
very
generic.
I
said
that
it
could
be
issued
closer
issue
open.
So
you
can
imagine
that
issue.
A
Closing
issue
open
are
also
events
here
and
then
you
can
see
them
in
a
scatterplot
or
another
event
could
be
pipeline,
kicked
off
or
yet
another
event
which
starts
getting
to
users,
which
is
interesting,
is
that
you
know
a
product
manager
commented
on
this
issue
or
a
developer
commented
on
the
load
request.
A
reviewer
maintainer
did
that
a
security
person
commented
on
something
or
participated
sometime.
A
We
start
tracking,
more
and
more
of
those
events
and
we
let
people
analyze
those
events
and
then
finally,
the
the
concept
of
a
board
does
come
back,
but
it
doesn't
have
to
be
tied
closely
to
a
board.
But
the
concept
is
that
once
you
have
those
events,
then
you
can
create
a
board
or
you
can
associate
it
with
a
board.
So
I'll
stop
there.
A
I'm
looking
for
is
idea
of
this
is
a
good
idea,
a
bad
idea,
especially
because
it's
very
different
from
a
previous
idea,
with
the
stages
I,
don't
think
you're
in
that
one
meeting
Pedro,
but
in
that
one
I'll
try
to
dig
up
those
designs
right
now
and
then
to
answer
your
question
but
yeah
that
there's
your
question
paper.
That's
what
I'm
saying
looking
for
feedback
on
whether
this
is
a
good
idea,
but
I
like.
B
B
C
A
A
What
end
to
end
is,
but
at
a
high
level
like
when
we
talk
with
customers,
were
we
don't
get
into
detail
and
say,
like
you
know,
when
what
is
your
issue
considered
started,
but
we
all
we
often
at
least
start
with
saying
that
we
wanted
a
total
time
that
it
took,
for
you,
know,
development
of
a
feature
to
get
it
pushed
into
production,
so
that
is
most
important
as
a
first
levels.
We've
started
to
complete
and
some
notion
of
that,
and
so,
for
example,
the
psycho
analytics
we
are.
A
From
last
time
we
said
that
we're
gonna
invent
custom,
workflows,
first,
meaning
that
you
have
defined
these
workflow
stages
similar
to
jerem,
and
these
are
not
labels
and
then
the
issue
enters
these
stages,
one
by
one,
and
you
drag
them
in
whether
an
issue
board
or
whether
you're
issued
to
go
through
these
stages.
And
then
once
you
have
this,
we
build
VSM
on
top
of
this
and
then
some
of
the
designs
animal
started
to
work
on
is
that
dsm
was
really
tied
down
to
this.
C
Go
ahead,
I
just
asked
what
I
asked,
because
you
mentioned
some
events.
That
seems
to
be
important
for
the
the
main
goal
of
the
user.
Knowing
what
is
the
time
that
it
took
from
the
creation
of
the
issue
or
the
starting
of
the
development
into
you?
It
was
in
prediction
and
then,
like
the
label
started
and
completed,
makes
sense,
but
you
mentioned
also
events
for
like
comments,
war
for
right
things
that
could
be
like
in
a
future
iteration,
maybe
yeah.
A
And
so
so
those
events
I'm
saying
that
that
this
design
using
stages
does
not
make
it
really
easy
to
unlock
those
features
that
we
potentially
want
to
build,
and
so
like
people
commenting,
that
might
not
seem
very
realistic,
but
even
even
if
we
don't
do
that,
if
we
do
something
more
generic,
just
using
stages,
I
already
see
some
some
things
that
are
troubling
to
me
and
which
is
when
you
look
at
this
model
it.
It
is
a
very
waterfall
model.
A
It
assumes
that
there's
little
collaboration
happening,
for
example,
at
what
we
do
I'd
give
that,
for
example,
when
you're
in
the
review
stage
is
that
only
developers
as
their
designers
here
or
when
you're
in
development
is
their
designers
here
or
like
is
there
security
stakeholders
is
their
marketing
people
as
their
sales
people.
So
those
things
at
get
lap
are
happening,
I
mean
we
can
always
improve,
but
this
design
does
not
lend
itself,
naturally
or
I.
A
That's
all
we
care
about
which
is
great
in
the
beginning,
but
I'm
arguing
that
it's
dangerous
because
it
ties
us
down
in
terms
of
design
for
future
features,
and
so
in
the
beginning,
of
course,
what
we're
going
to
do
is
get
to
end
the
end
time
and
also
what
we
talked
about
last
time
is
once
we
know
the
end
to
end
time,
then
we're
going
to
say:
okay,
how
about
the
development?
How
about
the
in
review
time
in
the
ready
time
like?
A
C
A
So
you
can
do
all
those
things
right
and
then,
but
you,
you
already
need
to
invent
all
these
new
attributes
and
metadata
to
measure
waiting
time
that
you
just
brought
up.
You
look
at
the
events.
That's
actually
I
would
argue
fairly
straightforward,
because
you
can.
You
can
create
an
event
that
says
you
know
entered
this
stage
and
then
you
have
another
event
that
says
first
person
you
know
took
an
action
on
that
issue
and
then
right
away,
you've
defined
the
waiting
time.
A
So
what
I'm
arguing
is
not
for
the
specific
use
cases
I'm
arguing
for
this
is
a
good
baseline
design
and
a
good
architecture,
a
good
information
architecture,
a
good
engineering
architecture.
And
then,
let's
pick
the
specific
use
cases-
and
maybe
you
know,
create
those
first
set
of
events
to
really
address
those
first
weeks.
Cases
and
I
argued
the
first
set
of
use.
Cases
should
be
calculating
end
to
end
time
right
here
and
end
time,
but
what's
after
that
is,
it
is
a
waiting
time.
A
Like
you
just
said:
well,
Mar,
is
it
gonna
be
individual
stage
time
or
is
it
gonna
be
like
what
I
said
earlier
about
measuring
when,
like
the
scatterplot
something
like
this?
So
it's
not
clear
to
me
what
those
are
or
maybe
we
should
invent
stages
right
now
that
I'm
not
saying
this
is
a
bad
idea
right
now,
so
this
is
one
of
the
purposes
of
this
meaning
it
could.
A
We
could
be
saying
that
to
instead
of
using
labels
which
I,
which
we
can
do
right
now
right
to
to
quantify
these
things,
we
could
have
still
in
the
end
stages
right
away,
but
we
still
use
events
under
the
hood
to
calculate
value
stream
mapping.
We
say
that
there's
a
vent
that
enters
this
stage
and
maybe
exists
it.
C
B
C
B
A
B
A
Right
well,
I,
wonder
you
have
some
I,
don't
know
confirmation,
but
like
confidence
from
confirmation
from
the
team
here
right,
you
know,
I,
see
everybody's
experts
here
to
say,
like
the
underlying
support
system,
events
makes
sense
number
one
and
then,
if
that
makes
sense,
then
what
should
we
do?
Should
we
do
custom,
workflows
and
and
keep
arguing
about
them
shouldn't
be
based
on
labels
and
first
classes
and
like
stages
or
should
we
do
labels
because
we
have
labels
already
or
should
we
do
something
else?
A
Because
because
we
can
do
this
and
we're
still
not
solving
custom
workflows
in
a
very
nice
way
right,
so
so
what
key
value
labels
or
scope
labels
that
they're
called
now
our
issue
boards
won't
be
as
annoying
anymore
and
people
can
move
them
through
the
stages
and
they'll
be
mutually
exclusive,
so
they
can
advance
someone
on
the
issue
so
that
that
is
a
net
improvement.
So
if
we
keep
on
going
down
that
route,
I
can
imagine
a
future
where
we
keep
kicking
the
can
down
the
road
and
we
never
do
first-class
stages.
A
D
B
A
B
B
A
Would
be
so
it
wouldn't
do
the
latter,
because
the
first
iteration
wouldn't
have
it,
and
you
can
also
impose
an
order
on
scoped
labels,
so
they're
neutral
from
that
perspective,
like
both
of
them,
can
enforce
an
ordering.
But
the
benefit
of
doing
first-class
stages
is
just
that:
we're
not
using
labels
and
I.
Think
that's
the
declare
benefit
right.
It's
when
we're
adi
overloading
labels.
If
that's
a
word
like
we're
subtracting
that
paint
where
that
paint
still
exists
right
now.
A
But
we
don't
have
to
slow
down
a
value
stream,
mapping
or
management
whatever,
partly
because
we
can
use
label
events
right
away,
and
so
we
can
start
this
work
and
have
folks
define
things
like
labels
here,
which
is
already
a
feature
of
great
improvement.
But
if
we
ever
need
to
go
back
and
say
a
new
event
based
on
first-class
workflow
stages,
we're
not
blocking
that-
that
is
still
always
possible,
and
then
you
can
do
the
other
way
around
as
well.
You.
A
B
A
B
A
B
F
B
A
A
A
I,
do
I
don't
look
at
as
a
resourcing
problem,
I
look
at
it
as
a
like.
We
get
it
sooner
or
later
that
trade-off,
so
so
I'm
not
saying
that
we
have
I'm
leaning
toward
that
way.
But
I
want
this
to
be
an
open
discussion
to
say
that
you
know
it's
a
terrible
experience
to
do
it
with
labels
and
if
you
know,
if
I'm
convinced
I
will
I
will
argue
for
that
with
other.
You
know,
folks
and
okay.
B
B
What
do
you
think
so?
Maybe
you're
more
inclined
to
do
value
stream
with
the
labels
first,
because
I,
hopefully
that
can
solve
a
lot
of
the
use
cases
for
custom
workflows
and
a
lot
of
customers
and
people
that
would
initially
want
custom
workflows
can
are
now
less
annoyed
and
less
proponents
for
custom,
workflows
and.
A
A
So
there's
some
value
there
right
beyond,
like
the
basic
product,
usage
and
adoption,
is
to
show
to
the
world
like
we're,
taking
value
stream
as
being
like
there's
only
so
much
we
can
say
like
for
I,
don't
know
like
a
year
now,
then
we
have
all
these
issues
and
like
party
marketing
materials.
But
like
the
moment
we
can
say
on
a
blog
post,
we
have
it
and
the
moment
we
can
tell
customers,
we
have
it
and
show
them.
A
This
is
how
it's
used
that
opens
up
a
whole
new
door
of
other
possibilities,
and
that's
that's
really
good
labs
secret
sauce
and
might
not
the
other
secret
sauce,
but
it's
our
secret
sauce,
so
so
I'm
indexing
on
that
as
well.
But
if
we
have
to
wait
like
one
iteration,
we've
waited
like
like
a
years
so
I
could
be
convinced.
The
other
way
as
well,
and
we
should
do
stages
first,
like
first
castes
and
then
in.
F
F
D
A
D
Why
am
I
asking
this
actually
is
because,
like
then,
we
kind
of
integrate
a
little
bit
with
the
stages
stuff
Rika's,
because
these
sculpt
labels
are
sort
of
supposed
to
emulate
the
these
stages
in
a
way
because
then
you
have
this
them
mutually
exclusive
that
you
cannot
have
like
started
and
complete
label
on
on
the
same
issue.
At
the
same
time,
yeah.
F
Hoped
labels
so
as
they
serve
a
different
function
as
well.
I
mean
on
one
hand
they
could
play
the
role
of
being.
You
know
defining
these
steps
in
the
value
stream,
but
they
could
also
play
another
role
of
being
a
custom
field
as
being
true
false
or
you
know,
size,
small
medium,
large
I.
Think
there's,
but
think
in
this
place
is
the
idea
that
we're
overloading
these,
which
is
okay,
I,
think
I
mean
it
can
get
your
head
around
I
think
it's
okay.
We
just
have
to
teach
people
how
they
work.
Yeah.
D
Yeah
also
the
ideas
from
the
UI
perspective.
Maybe
we
should
start
thinking
about
kind
of
differentiating
a
little
bit
between
them
in
the
UI.
We
have
I,
guess
I'm,
just
throwing
it
from
top
of
my
mind,
like
we
probably
have
a
different
page
for
configuring
them
I'm,
not
sure,
and
this
way
we
would
kind
of
separate
them
a
little
bit
from
there.
The
normal
labels.
E
F
A
D
Like
again,
what
I'm
thinking
about
is
then
I
guess
with
this
whole,
definitely
overlord
labels
more.
If
we're
going
going
to
move
this
path
and
then
having
the
ability
to
separate
them
from
like
separate
labels
from
scoped
labels
and
being
able,
then
to
L
to
add
some
rules
or
something
else
on
top
of
the
scoped
labels.
D
So
when,
if
you
are
able
to
separate
them
visually
in
the
UI
people
to
see
them
as
different
things,
so
those
that
overloading
will
be
a
less
of
an
impact,
in
my
opinion,
I'm,
not
sure,
that's
how
how
I
kind
of
perceive
it.
If
you
kind
of
show
them
as
different
things,
then
people
will
perceive
them
as
different
things
and
they
have
slightly
different
functions,
although
you
can
definitely
use
them
as
normal
labels
as
well.
A
A
E
I
was
going
to
say,
or
there
was
I,
do
like
I
like
your
idea
and
they're,
not
tracking,
because
we
seem
to
be
able
to
get
quite
a
few
things
for
free.
Where
are
any
time,
stamping
all
these
things,
I
also
like
that
it
is
sort
of
automated
you
don't
have
to
manually
drag
things
around
like
you
would,
with
a
JIRA
style,
custom
workflow
to
a
certain
extent.
I
have
a
question,
though,
about
the
like.
In
your
example,
you
have
completed
and
started
as
just
regular
labels.
I'm
trying
to
think
is
this.
A
A
So
if
you
do
this
for
the
like,
maybe
a
first
iteration-
maybe
it
won't
even
be
this,
but
like
for
the
good
lab
use
case,
we
don't
care
about
the
entirety
lab
or
you
get
that
or
for
say
a
particular
team
or
even
a
particular
department
for
that
matter
so
similar
to
boards.
You
need
to
have
an
object
and
you
need
to
further
scope
it
right,
so
you
may
be
it
small.
A
So
maybe
it's
labels
or
whatever,
and
so
you
have
some
scoping
that
says
narrow
the
the
the
population
of
issues
that
you
care
about
and
associated
with
that
object.
And
then
that
is
your
dsm
object
for
your
team
for
your
department
for
you
as
a
director
that
you
care
about
whatever
it
is
and
then
from
there
you
make
additional
configuration,
which
is
against
so
much
lists
in
a
board.
A
A
A
Yeah
yep,
so
so
to
me,
that's
that
is,
that
is
not
like
something
that
the
platform
doesn't.
So
what
I'm
proposing
is
a
platform
or
it's
a
baseline,
using
events
and
then
so
you
can
build
on
top
of
that.
So
I
would
agree
you're
totally
right
with
stages.
Then
you
won't
get
those
data
errors,
but
even
for
stages.
For
example,
what
if
issues
are
moving
around
from
stage
to
stage
so
then
that
data
is
not
really
technically
correct,
because
then
there's
rework
and
other
things
right.
A
A
So
we
can
have
a
VSM
world
where,
like
my
scatter
pod,
which
not
too
many
people
are
excited
about,
we
can
log
something
that
says,
like
you
know,
logging
a
bug
like
when
did
that
happen,
and
then
you
can
have
some
new
for
that.
I
think
as
a
first
step.
If
we
wanted
to
constrain
it,
I
would
have
no
problem
with
that,
because
it's
better
to
constrain
it
at
the
beginning,
then
than
later.
A
So,
if
we
wanted
to
say
that
you
can
only
choose
scope,
labels
to
start
off
with
or
maybe
choose
a
given
set
so
that
you
get
this
view
sort
of
automatically
I
think
that
could
be
an
interesting
solution
as
a
first
MBC
as
well.
So
I
wouldn't
be
against
that
that's
interesting
John
did
you
want
to
say
something.
F
Want
to
say
two
things
actually
say
you
can
say
three.
Thank
you,
I
appreciate
that
hey
so
I'm
thinking
about
this
and
first
thing
that
kind
of
blew
my
brain
as
I
was
thinking
about
the
sequencing.
We've
talked
about
enforced
workflow,
where
there's
a
starting
spot,
but
you
have
here
started
in
review
in
UAT
and
complete,
so
you
could
establish
an
organization
could
say
a
customer
could
say
for
all
of
my
projects.
F
They're
gonna
go
step,
one
two,
three
four,
which
is
cool,
but
when
we
were
talking
out
about
events,
I
thought
about
this
from
an
enforcement
perspective,
there's
really
three
different
ways.
You
could
have
enforcement
or
imposition
of
the
order
of
an
organization
wanting
to
have
a
certain
value
stream
flow.
One
is,
they
could
say,
do
it,
however,
you
want
do
whatever
makes
sense
to
do
it.
Your
project,
you
figure
it
out,
you
guys
are
smart
figure
it
out,
and
then
they
could
learn
from
that
too.
F
You
could
have
a
rule
of
a
more
rigid
structured
organization
like
financial
service
or
others
they're,
going
to
impose
a
here's,
the
order
we
want
you
to
follow
and
I
think.
The
third
scenario
we
could
end
up
with
is
a
scenario
where
the
organization
says
hey.
These
are
the
five
activities
you
have
to
do.
You
guys
figure
out
the
order
and
the
sequence
you
do
them
in
and
we'll
learn
from
following
along
so
I
think,
there's
three
different
ways
that
we
could
approach
solving
this.
Those
first
thing
this
this.
F
The
second
thing
that
I
think
is
more
important.
We've
got
to
get
on
our
radar
and
make
sure
we're
addressing
here
and
and
we're
gonna
make.
This
will
make
it
even
more
important.
Is
that
we've
heard
from
customers
they
want
to
have
the
ability
to
imply
group
templates
or
group
structures
on
their
on
their
project
so
that
they
have
the
same
structure
the
same
labels
in
a
repeatable
way
to
consistent
ways
that
when
I
create
a
new
project,
it
shows
up
in
the
same
way,
that's
going
to
be
as
we
go
down
this
path.
F
We're
gonna
make
that
capability
even
more
important
and
I,
don't
know
where
it
is
in
our
backlog,
but
the
ability
to
say
for
you
in
my
group
and
my
set
of
projects
I
want
them
all
to
look
more
or
less
the
same
with
the
same
labels
in
the
same
structure
in
place.
I
think
that's
gonna,
be
something
we're
gonna
have
to
look
at
prioritizing
as
we
go
forward.
Yeah.
A
A
What's
really
great
is
that
you
can
have
this
at
the
group
level
and
then
you
can
at
the
project
level
inherit
it,
especially
if
these
are
labels
or
events.
We
didn't
even
talk
about
like
events
scoping
so
I
think
that's
that's
all
relevant,
but
again
with
the
events.
I
think
it's
all
a
lot
more
flexible
than
stages,
because
eventual
just
totally
with
it
just
points
in
time
in
the
database,
and
so
it's
really
easy
to
to
query
them.
So
I'm
excited
about
that
approach.
I'm
with
you
and
mentally
I've
moved
on
so
I'll
answer.
A
A
B
A
A
So
I
wanted
to
step
back
and
talk
about
maturity.
I,
don't
think
I've
actually
brought
it
up
with
this
group,
which
is
I,
should
have,
but
we
have
maturity
models
for
gitlab
and
they're
based
on
product
categories,
so
maybe
I
should
a
little
side
step
or
step
somewhere
else.
So
we
have
product
categories
and
we
group
our
features
into
two
categories,
so
the
planned
stage
has
has
a
number
of
categories
right.
A
So
it
has
project
management,
Kanban
boards,
time
tracking,
these
eight
categories
here
so
3,
plus
3
here
and
then
plus
2
here
so
there's
8
categories
and
then
don't
worry
about
the
group.
We
talked
about
that
last
time,
so
just
think
of
them
as
within
the
plans,
nature's
8
flat
categories,
and
we
want
to
advance
them
in
maturity
and
the
reason
there's
a
couple
of
reasons.
We're
wanting
to
do
this.
A
We
want
to
make
management
of
this
a
little
bit
easier
at
a
higher
level,
so
there's
visibility
and
that
we're
advancing
our
product
and
we
can
measure
how
you
know
how
we're
improving
gitlab
from
a
breadth
or
depth
perspective.
So,
even
though
we're
we
operate
as
individual
teams
and
stages,
and
we
want
to
move
quickly
and
we
make
our
own
decisions
largely
make
our
own
decisions,
we
have
to
also
make
people
aware
of
said
decision
that
we
have
to
work,
as
you
know,
entire
collab.
A
Together,
we
know
we've
identified
things
that
we
view
okay,
ours
and
so
the
maturity
model
helps
in
this,
even
though
it
may
seem
arbitrary,
but
it
III
see
it
as
a
mean
cent
and
it's
a
means
for
structure
and
planning,
because
there's
so
much
functionality
lab
you
can't
like
line
up
every
single
feature
in
a
spreadsheet
and
say
you
know
we're
gonna
do
this
versus
this
and
how
does
it
this
impact
hiring?
How
does
this
impact
you
know
she's
telling
our
customers
about
a
road
map
so
on
and
so
forth?
A
So
this
is
one
way
to
serve
that,
so
you
can
see
that
we've
defined
again
somewhat
arbitrary
definitions
of
a
product
category
being
minimal,
viable,
complete
and
loveable.
And
again,
as
you
would
guess,
our
goal
is
to
push
our
product
categories
toward
lovable,
and
if
we
have
this
type
of
abstraction
and
structure,
we
don't
have
to
get
into
the
features.
We
can
have
a
conversation
and
say
you
know,
for
the
plan
team
I
want.
You
know
these
categories
inside
into
lovable
by
this
state
and
so
on
and
so
forth.
A
So
we've
done
exactly
that,
and
so
we
have
these
very
ambitious
goals
and
they're,
really
really
ambitious
and
and
they're
predicated
on.
Not
the
current
state
of
affairs
are
predicated
on
our
hiring
plan
so
that
we're
assuming
that
we're
gonna
hire
more
folks
doing
more
things,
make
these
team
splits
and
move
quickly
and
so
on
and
so
forth.
So
you
can
see
from
here.
A
We
are
claiming
that
project
management
in
combat
boards
and
time
tracking
is
already
minimal,
we're
claiming
that
you
want
to
be
complete
and
unlovable
by
these
states
and
so
on
and
so
forth.
Why
this
is
relevant
to
your
question.
Page
o
is
from
one
from
an
aspect
of
us
wanting
to
do
these
things
it's
relevant,
and
then
we
can
step
back
to
say
like.
Why
do
we
even
want
to
make
these
targets
so?
But
let
me
adjust
this
first,
so
value
stream
management.
A
You
can
see
it's
its
own
category
and
we're
claiming
that
or
we're
planning
it
to
be
minimal
very
soon.
So
this
is
yet
maybe
is
another
reason
we
want
to
do
it
sooner
rather
than
later.
We
just
want
to
hit
this
target
from
a
planning
perspective
right,
so
this
is
yet
another
input
to
that
and
then
workflows.
A
Customer
clothes
currently
is
within
project
management
and
I'm
fairly
certain
that
I
put
that
under
complete
but
I
might
have
removed
it,
because
I
might
argue
that
custom
workflows
is,
you
know,
gonna
be
accomplished
for
scope
labels,
so
I
think
I'm
still
deciding
that
and
sort
of
not
have
that
tight
tidied
up
really
clearly
and
I
should
do
that.
But
to
make
a
point
here,
specifically,
custom
workflows
is
falls
on
the
project
management.
A
It's
already
a
project
management,
as
the
category
is
already
quite
advanced,
whereas
value
stream
management
is
non-existent
and
it's
not
even
minimal,
and
so
therefore
we
wanted
to
this
and
then,
from
the
perspective
of
you,
know,
customer
feedback
and
then
do
we
want
this.
How
important
this
is.
This
is
informing
that
right
this,
this
maturity
model
is
supposed
to
inform
it.
So
we
see
a
huge
opportunity
with
value
stream
management.
It's
a
new
area.
We've
been
emphasizing
depth
of
breath
in
psychie
11.
A
This
is
an
example
of
that,
where
this
is
a
huge
new
category
that
we
want
to
play
into.
We
have
we
participated
in
Forrester
last
year
and
we
haven't
even
moved
inch,
and
so
this
is
the
reason
we're
pushing
for
a
balance,
tree
management
and
then
custom
workflows
is
one
of
those
things
that
customers
have
always
asked
for,
like
it's
one
of
those
like
probably
three-year
issues
right
and
it's
something
that
we've
been
making
incremental
improvements
toward,
for
example,
the
issue
board
itself
is
one
and
then
now
scope.
A
Labels
is
one
so
we're
moving
toward
that
direction.
So
it's
important
for
existing
customers
and
then
value
stream
management
is
important
for
future
customers
and
existing
customers
and
it's
more
strategic
because
it's
something
that
doesn't
exist
yet
and
so
the
return
there
is
higher
from
from
a
more
riskier
perspective,
because
the
we're
going
to
be
opening
new
avenues
of
sales,
for
example
new
customers
that
are
interested
in
this
thing
and
higher
levels
of
this.
A
This
will
be
an
ultimate
feature
right,
so
I'm,
tiers
and
so
on
and
so
forth,
so
that
all
feeds
in
doing
custom,
workflows,
I,
think
I
put
in
a
premium
so
that
all
feeds
into
why
it
seems
that
I
don't
know
if
you
feel
that
way,
but
I'm
trying
to
communicate
that
VSM
is
more
urgent
than
say.
Customer
closes
yeah.
B
A
A
B
B
I
would
love
to
see
that
in
the
epic
itself,
like
saying
why
we're
doing
this,
like
X
number
of
customers,
have
requested
this,
where
we
have
Forester
that
thinks
that
this
will
grow
by
X
percent
in
that
few
next
year's
and
for
both
custom,
workflows
and
and
value
stream
management.
Try
to
to
make
it
a
bit
more
tangible
because
that
I
think
we're
we're
I,
think
we're
just
kind
of
assuming
and
and
in
terms
of
assumptions.
B
I
we're
very
one
of
the
assumptions
that
we're
very
sure
about
is
what
you
just
said:
Valley
Stream
Management
is
riskier
because
we
still
don't
know
what's
going
to
happen,
it
sits
in
a
venue
for
businesses
for
business,
but
it
can
also
be
a
time
sink
right.
We
can
be
building
all
of
this,
and
maybe
we
don't
have
that
much
adoption
compared
to
if
I
build
custom
work.
It's.
B
So
it's
it's
a
gamble
for
value
stream
management.
Custom
work
was
a
bit
more
so
so,
basically,
knowing
this
I
was
just
looking
to
see
why
customer
data
who
we've
talked
to
what
they've
said.
What
is
the
industry
saying
to
back
up
our
strategy?
Essentially
because
I'm
not
seeing
that
right
now,
yeah.
A
Thanks
page
on
I'm,
taking
notes
so
that
I
can
do
that
homework
so
I'm,
not
ignoring
you
and
I,
think
what
you
covered
I
think
in
relation
I
think
what's
difficult
are
not
difficult,
but
there's
a
lot
of
dependencies
with
custom
workflows
here,
so
I
think
that's
relevant
to
to
put
all
that
together.
Some
of
that
information
is,
is
there
Pedro,
so
maybe
I
meet?
Let
me
share
that
really
quickly
and
then
I
can
I
think.
What's
definitely
missing
is
the
relationship
to
custom
workflows.
A
A
That
is
written
here
like
the
description.
Why
we're
doing
this
analyst
so
and
so
forth?
So
a
lot
of
this
here,
I,
don't
think
I've
done
a
good
job
of
tying
to
custom,
workflows,
I
think
that's
that's
actually
pretty
relevant
here,
so
I
will
I
will
definitely
update
this
and
I'll
ping
you
on
this.
So
you
can.
You
can
read
it
read
this
as
well,
but
we
have
this
for
every
single,
nothing
like
a
business
case
for
it,
which
is
exactly
which
is.
We
definitely
want
that
rate
all
right.
Okay,
I.
B
A
But
while
I
clean
up
that
mess,
everybody
can
go
feel
free
to
go
against
this
product.
A
very
facially
can
navigate
to
this
by
now.
But
if
you
click
on
each
category,
you
care
about
other
categories
and
I
give
up
like
part,
managers
are
responsible
to
essentially
have
have
a
business
case
for
every
single
category.
So
it's
not
just
a
feature.
This
is
like
just
the
general
area
in
a
product.
A
A
And
so
you
can
look
at
each
of
these
and
then
they're
all
templated,
meaning
like
there's
words,
are
sections
in
these
ones
with
hopefully
some
words.
So
so
please
go
ahead
and
read
the
ones
that
you
care
about,
in
particular
battery
management.
I
think
is
the
relevant
here,
and
so
so.
I
have
written
some
things,
especially
with
that
the
analyst
piece
so.
B
A
B
A
Have
I
mean,
but
that
that's
what
it
is
like,
the
the
top,
these
things
are
going
to
be
well.
I
mean
these
are
issue
right,
I,
didn't
piece
every
single
issue,
but
the
I
linked
to
this
one.
But
it's
it's
really
the
entire
epoch
right.
So
it's
the
entire
design,
it's
the
three
or
four
epochs.
So
maybe
I
should
do
that
page.
Oh,
that's,
fair,
but
what
we're
we're
talking
with
customers?
But
it's
not
like
it's
not
like
issue
boards
where
they
have
like
10
requests
and
what
they
want.
A
B
Like
what
is
the
weight
of
this
for
four
customers,
and
even
if
we
don't
have
issues
because
customers
don't
know
what
they
want
right
and
they
can't
create
an
issue
saying
I
want
this
specifically
or
I,
want
this
improvement,
I.
Think
having
a
summary
of
the
discussions
that
you've
been
having
with
customers,
it
would
be
really
important
like
and
because
again
they
don't
know
what
they
want,
and
if
you
can
translate
that
into
something
that
we
can
then
pair
with
the
analyst
landscape
with
the
competitive
landscape
right,
it
will
help
understandings.
A
C
Maybe
we
could
call
them
stages
which
of
the
stages
in
the
value
stream
are
more
valuable
than
others
in
the
in
the
complete
stream
and
then
in
a
way,
right,
educate
the
the
customers
in
looking
to
the
value
stream
and
seeing
which
ones
are
more
valuable
than
others
and
and
then,
if
they
see
that
something.
That's
not
that
valuable
is
taking
too
much
time,
educating
them
with
like
good
practices
that
they
could
reduce
the
time
in
that
specific
stage,
or
something
like
that.
C
Make
an
example
like
for
software
development:
you
we
have
like
stages
in
the
value
stream,
let's
say
UX
and
design,
it's
something
that
adds
value
and
it
happens.
It
will
happen
in
different
for
the
development
of
different
products,
and
the
development
itself
also
adds
most
of
the
value.
And
then
there
is
like
testing
and
things
like
that,
which
happens
in
all
the
or
should
happen
in
every
every
could
happen
in
every
project
that
doing
software
development,
for
instance.
So
I
don't
think
it's
so
specific
to
they
should
to
specific
customer
I.
A
Yeah,
it
is
specific
to
a
customer
but
I
think
Walmart
what
it
doesn't
have
to
be.
I
think
what
you're
suggesting
is
great,
because
we
can
have
either
you
know,
representative
examples
or
whatever
and-
and
you
know
mention
that
you
know
for
regulated
industries
like
as
John,
was
saying
that
you
know,
there's
gonna
be
more
stages
or
there's
gonna,
be
a
security
review
stage,
or
things
like
that
and
know
and
write
those
things
down.
A
I
think
is
what
you're
saying
so
how
we
can
represent
that
I
think
is
relevant
so
that
you
know
in
in
finance
they
they
always
need
a
clear
UAT
stage
or
something
that
or
this
is
what
we've
observed,
or
this
is
what
customers
are
saying
that
that
they
always
need
this,
and
that
will
help
the
design.
It's
not
that
we're
going
to
use
them
or
help
specifically
or
predefined
them,
but
that
it
will
help
drag
the
design
and
discussion,
so
I
think
there's
definitely
some
value
there.
A
So
yeah
I
agree
with
that
and
we
can
work
out
that
together
all
right,
I
think
this
is
good
timing,
so
I
think.
The
summary
is
that
folks,
like
the
events
thing
I,
don't
see
a
huge
push
back
to
do
custom
stages
right
now
or
custom
workflows,
so
I
think
that
issue
is
already
scheduled
for
doing
the
first
label
thing
so
we'll
just
let
the
process
run
and
we'll
let
whoever
works
on
it,
drive
it
from
a
UX
perspective
and
then
I'll
continue
to
add
more
background.