►
From YouTube: Kanban Q&A - Release
Description
Review the Kanban Process for the Release Stage
B
C
A
Certainly
I
can
be
re,
am
I'm
actually
gonna
be
answering
my
own
question.
Then
this
is
kind
of
cool
I
love
that
or
EADS
question
was
about
the
scheduling
board
versus
what
gets
the
CIC
the
active
label
when
and
by
whom
is
this
equivalent
to
the
issues
in
the
current
milestone
so
to
break
this
down?
A
I
have
been
adding
something
to
the
CIC
the
active
build
board
when
it
has
a
weight
and
it's
been
groomed
and
it's
in
the
scheduling
workflow
at
that
time,
John
will
then
add
ready
for
development
and
I
will
stack,
rank
it
or
assign
a
priority
based
on
if
it's
going
to
be
executed
against
in
the
current
milestone.
So
I
think
that
answers
all
of
the
stuff,
but
you
can
have
things
based
on
the
process
that
geo
is
doing
and
package
is
doing.
A
You
can
have
things
in
the
ready
for
development
column
that
are
weighted
and
groomed
and
ready
for
people
to
be
worked
on,
but
they
don't
have
a
milestone
on
them.
They're
in
the
backlog.
It's
just
an
indicator
that
this
is
scope.
That
engineering
can
pick
up
because
it's
been
groomed
and
it's
important
to
deliver.
C
That
question
came
up
a
couple
times
on
our
release:
management
weekly
today
of
basically
there
are
issues
and
ready
for
development
that
don't
have
a
milestone
assigned
to
them.
When
is
the
correct
time
to
assign
a
milestone
we
jockey
now
I.
Think
last
week
we
started
typing
up
a
little
bit
of
instructions
around
that
in
our
release
management
planning
document.
We
have
not
published
that
yet
hopefully
early
this
week,
but
it
essentially
says
like
when
you
pick
up
an
issue.
Please
there's
a
checklist.
It's
like
please
assign
yourself.
D
So
this
is
a
this
is
an
important
cause.
I
think
this
came
up
in
some
discussions
today
as
well.
This
is
what
what
you
guys
are
doing
is
essentially
assigning
like
the
engineer,
is
picking
up
the
issue
signing
themselves
and
then
determining
the
milestone,
though,
that
pulley
like
reshaping
yeah,
okay.
D
So
as
an
example,
if,
if
there's
like
a
week
left
in
them
before,
you
know
our
unofficial
cutoff
date-
and
you
think
this
thing
is
gonna
take
a
couple
weeks
to
do,
then
just
go
ahead
and
give
it
the
next
milestone
like
be
realistic
about
it,
even
though
we're
currently
working
in
twelve
eight,
you
think
all
those
there's
not
a
good
chance
that
this
will
get
into
twelve
eight,
then
just
just
give
it
give
it
a
reasonable
milestone.
If
it
doesn't
happen
already,
that's.
C
A
I
would
say
that
as
a
product
manager,
I
would
want
my
Mr
weight
to
reflect
your
milestone.
So
if
it's
a
one,
mr
and
it's
the
beginning
of
the
milestone,
it
seems
kind
of
strange
for
that
to
be
marked
for
12.9
delivery.
So
just
be
cognizant
of
how
you're
waiting
issues
and
what
you're
scheduling
as
an
engineer.
D
Yeah
I
think
I
think
that
makes
a
lot
of
sense,
I
think
the
early
in
the
milestone.
It
seems
pretty
likely
that
something
would
get
done
if
it's,
if
it's
a
small
enough
issue,
I,
think
the
timing
when
it
gets
a
little
questionable,
is
when
we're
kind
of
running
up
close
to
that
cutoff
date
and
not
wanting
to
communicate
the
wrong
thing
or
no
one
wants
to
slip
a
milestone.
So.
C
B
Sorry
I
was
trying
on
mute
just
a
question
on
that.
If,
for
example,
you
in
that
scenario,
we
would
assign
it
to
1212
that
I,
you
know
optimistically,
then
it
doesn't,
you
know
it
doesn't
make
it
until
then
it
would
we
see
the
mist
12.8
label,
so
you
said
something
we
want
to
try
and
avoid
is
at
the
mist
label
in
general,
or
does
it
not
have
that
much
significance
so.
A
For
the
items
that
we
start
a
milestone
with
so,
for
example,
I
have
those
three
issues
that
were
assigned
to
talk
to
me
at
the
beginning
of
2008.
We
would
want
to
avoid
adding
this
miles,
missed,
milestone,
numbers
tags,
labels
to
those
issues,
I
think,
once
you
pull
something
into
a
milestone.
The
understanding
and
transparency
that
we're
driving
with
our
customers
is
that
that's
going
to
be
delivered
within
that
milestone.
So
it
makes
sense
for
us
to
want
to
avoid
that.
A
B
D
Well,
the
one
thing
I
think
we
can
start
to
get
to
a
place
of
when
we
do
hit
those
missed
items.
They
become
sort
of
the
exception
case,
and
we
can.
We
can
retro
on
that
and
figure
out
what
happens
here.
So
if
it's
something
that
we
picked
up
in
the
middle
of
a
milestone
and
we
thought
we
could
get
it
done
and
then
it
then
it
didn't
happen.
Why
was
that?
Was
it
something
that
we
underestimated?
Did
you
get
hung
up
and
review
like
like
that
kind
of
stuff
I
think
we
can?
D
We
can
dig
into
that
a
little
bit
more
and
presumably
having
many
fewer
of
those.
Then
we
can.
We
can
actually
start
to
like
make
adjustments
to
to
like
respond
to
those
items
individually
like
if
it
is
a
maintain
a
review
issue
or
if
it
is
just
a
scoping
problem
or
something
like
that,
then
we
can.
We
can.
You
know,
react
to
that
accordingly,
so
we.
A
Shinya
is
the
next
one:
should
engineers
keep
watching,
build
board
only
or
schedule
and
plan
board
as
well.
A
release
management
is
doing
is
creating
research
issues
that
then
get
pulled
into
the
build
board
so
that
the
engineer
aren't
having
to
switchboards.
They
will
be
working
on
an
issue
technically
with
that
research
issue.
That's
on
the
Planning
Board,
because
the
assignment
is,
you
know,
break
down
the
implementation
issue,
but
the
actual
work
their
sign
is
only
on
the
Billboard.
So
that's
how
that's?
C
Like
that's
just
good,
that's
a
plate!
Okay,
it's
arms,
going
to
add
real
quick
to
just
the
Jackie
and
I
have
a
meeting
on
Thursday
where
we
review
the
schedule
schedule
board
and
that's
where
our
effort
is
to
make
sure
that
anything
that
needs
to
be
adjusted
is
adjusted
during
that
time.
Just
add
that
sorry,
oh.
D
So
in
progressive
delivery
were
we're
kind
of
taking
the
same
approach
in
there.
It
should
really
only
need
to
focus
on
the
Billboard
anything
that
is
a
research
issue
or
a
proof-of-concept
will
we'll
get
another
issue
spun
out
of
that
and
put
in
the
Billboard
and
yeah.
That's
the
intention
just
to
be
able
to
look
in
one
place
so
you're
not
having
to
jump
around
to
all
these
boards.
D
One
one
disclaimer
I'll
put
out
there
right
now
is
that
the
current
state
of
the
progressive
delivery
boards
needs
some
cleanup,
and
we
have
some
time
on
the
calendar
on
Thursday
to
do
that.
So
it
might
look
a
little
messy
right
now,
but
everyone's
got
their
work
kind
of
signed
out
for
for
this
milestone.
So
as
the
next
couple
weeks
ago,
by
we'll
get
that
all
cleaned
up
and
it'll
get
into
a
good
state
that
matches
with
this
workflow.
E
I
added
the
comment
from
the
the
next
point
here,
because
I
think
there's
also
kind
of
related
to
my
comment
on.
You
know
that
we
need
developer
is
assigned
to
those
issues
as
they
arise,
so
that
can
give
us
support
in
the
design
phase
so
that,
even
before
we
can
move
anything
from
InDesign
to
ladies
back
down
or
whichever
our
label,
it
is
that
we
have
the
right
support.
A
I
wouldn't
want
to
assign
and
developer
to
the
implementation
issue,
because
I
could
see
a
world
where
somebody
does
like
a
planning
breakdown
for
an
implementation
issue,
but
they're,
not
necessarily
the
one
that
instruments
the
issue.
So
I
would
say
that
we're
only
relying
on
the
research
issues
in
the
build
board
to
indicate
assignment,
but
we
can
iterate
on
that
I'm
open
to
assigning
them
to
the
Planning
Board
issues.
A
E
D
There's
there's
kind
of
two
ways
that
we've
been
talking
about
addressing
this,
which
is
one
you
like
pinging.
A
engineer
on
an
issue
is
still
like
a
totally
normal
workflow.
So
if
we're
working
on
design
and
we've
got
some
questions
like
you
can
ping
someone
and
say
hey
what
what
about
this
thing
and
like
that,
doesn't
follow
into
the
build
board,
but
that
that
should
still
fall
into
a
person's
to
Do's,
and
so
they
can.
They
can
see
that
and
respond
to
that
and
just
kind
of
a
normal
cadence.
D
D
C
That's
a
good
call,
I
think
I
think
we're
doing
the
same
kind
of
thing
where
our
needs
wait.
Issue
like
we
added
a
for
like
Jake
and
for
Nathan,
for
example,
they
have
a
complete
research
issue
called
out
there
that
links
to
an
issue
in
solution,
validation
on
the
on
the
planning
board,
but
it
kind
of
the
the
goal
is.
The
thought
here
was
hey
we're
not
they
don't
have
to
go.
Look
at
the
Planning
Board
per
se.
C
C
A
C
D
D
I
think
we
probably
need
to
you
know,
keep
doing
it
for
two
or
three
milestones
to
make
sure
that
it
kind
of
gets
ingrained
in
everyone's
workflow
and
it
doesn't
get
forgotten
about
and
then
and
then
kind
of
iterate,
but
not
to
be
too
quick
to
change
it
just
because
it
just
can
take
a
while
for
things
to
to
really
settle
in.
Given
our
cadence
here,
yeah.
B
Approach
is
quite
good
and
I
quite
liked
what
you
said
John
about
that
is.
We
should
time
boxer
to
four
hours.
You
know
approximately,
and
because
because
that
gives
you
an
idea
of
okay
yeah,
let's,
let's
do
some
work
to
dig
into
the
issue,
but
then
less
not
like
let
it
take
the
entire
day.
So
I
think
that
four
hours
you
have
two
sticks
quite
a
good,
quite
a
good
amount.
D
Yeah
I
think
that
time
box
is
important
to
keep
in
mind.
I
was
talking
about
Shinya
about
this
earlier
today
and
basically
like
using
that
as
the
distinction
so
like
I
can
look
at
this
issue.
I
can
attempt
to
get
my
head
around
it
and
put
some
weight
to
it
and
if
it's
gonna
take
more
than
an
hour
like
I
need
to
spin
this
off
into
something
else,
it
needs
to
be
like
we
need
to
escalate
this.
D
We
need
to
do
a
concept,
it's
gonna
take
a
couple
days
or
if
we
need
to
get
others
involved,
or
maybe
we
need
to
talk
to
someone
on
another
team
for
some
reason
like
okay,
this
thing
got
a
little
bit
bigger.
You
know
surface,
that
to
your
engineering
manager
or
your
product
manager,
or
whoever
and
like
like
elevate
this
to
something
else,
and
maybe
that
then
becomes
a
proof
of
concept
or
a
research
issue
that
gets
pushed
into
the
milestone
or
into
the
build
board,
because
there's
just
more
to
it.
D
A
A
Because
we
added
the
the
time
box
on
there
so
that
people
were
going
in
and
just
hammering
out
weights
on
these
issues,
so
we
can
get
a
feel
for
how
long
something
will
take
and
if
it's
worth
an
investment
now
or
later.
So
that's
where,
like
the
time
box,
is
really
important.
I
agree.
We
should
be
spinning
off
research
issues
if
it's
going
to
take
you
a
long
time
to
investigate
yeah.
D
D
All
right
you
move
under
in
his
next
comment:
yeah
I'll
play
the
part
of
shinu
this
time.
How
can
engineers
figure
out
the
current
priorities
quickly?
For
example,
an
engineer
is
assigned
to
an
issue
and
also
asked
by
another
engineer,
to
review
his,
mr,
which
should
this
person
start
working
on
at
first
I.
A
Release
p1
was
a
label
that
I'm
also
using
on
the
release
management
side
and
it's
what
we're
using
to
replace
planning
priority
I
also
assign
what
would
have
been
my
planning
priorities
to
the
milestone.
So
that
shows
the
stake
in
the
ground
that
this
is
what
we're
committing
to
as
a
team
to
our
customers
to
deliver
in
this
milestone
same
definition
of
a
planning
priority
and
then
I've
added
a
column
to
the
build
board
for
the
milestones
so
that
everyone
can
see
what
is
expected
from
a
planning
priority
with
the
milestone.
D
D
What
I
would
the
way
I
would
sort
of
think
about
triaging.
Those
two
things
is:
how
can
I
unblock
the
person
who
is
asking
for
review
as
quickly
as
possible,
and
does
it
doesn't
matter
if
I
do
that
now
or
or
later?
So?
If,
for
example,
you
are
in
Europe
and
you're
pinged
by
someone
who's
in
the
US
and
you
can
unblock
them
and
they
can
keep
working
on
that
thing
during
their
working
day,
try
to
try
to
get
back
to
that
sooner
Mike.
Maybe
do
that
ahead
of
the
feature
work
that
you're
working
on.
D
If
it's
a
case
where
they're
not
going
to
be
online
for
eight
hours
or
10
hours
because
they're
in
bed,
then
you
can.
You
can
kind
of
delay
that
thing
to
work
on
the
the
code
for
the
feature
that
you're
working
on
and
then
get
back
to
them
before
you
sign
off
for
the
day,
so
that
they
have
some
feedback,
so
they
can
get
started
in
their
morning.
B
That
does
make
sense.
Toby
I
just
got
a
question
about
and
I,
and
this
this
is
not
really
hasn't,
really
been
an
issue
for
myself,
but
I
can
imagine
for
someone
who's.
You
know
particularly
doing
a
lot
of
maintenance
work.
Do
we
are
we
doing
any
metrics
on
how
many
reviews
you
know?
Does
that
kind
of
go
into
the
mix
in
some
way?
You
know
like
we're
doing
X,
mojo
crisp
and
then
also
there's
all
these
reviews
and.
D
I
know
something
I,
don't
think.
This
is
something
that
we're
tracking
right
now,
but
we
probably
probably
would
be
helpful
to
I
I.
Do
know
that
it's
some
of
some
of
it
is
a
sort
of
a
thing
you
have
to
measure
for
yourself.
I
know:
I've
seen
people
that
that
turn
on
the
at
capacity
indicator
in
their
status
and
I
get
a
lot
of
status.
Saying
like
I
got
I'm
full
I
got
I
got
some
work,
I
gotta
do
I
can't
do
it.
Reviews
right
now,
so
I
think
that's.
D
E
I
was
looking
for
this
handbook
page
that,
because
we
have
this
information
about
how
designed
to
prioritize
the
work
and
in
the
engineering
workflow
there's
a
section
on
how
engineers
should
choose
something
to
work
on,
and
it's
pretty
much
safe
check
the
milestone
and
see.
What's
in
the
top
of
the
list
right,
it's
really
sorting
by
priority.
E
D
E
A
A
So
I
think
we
resolve
this
a
little
bit,
but
using
the
meta
issues
and
then
assigning
research
issues
and
the
build
board
will
avoid
them
being
assigned
to
issues
in
the
plan
board
for
now
and
we'll
stick
to
that
process
for
a
couple
milestones
and
if
we're
not
seeing
any
traction,
we
can
revisit
that
and
then
John
you
and
I
can
talk
in
our
one-on-one
about
creating
a
template
for
research
issues
and
maybe
adding
a
merge
request
of
that.
An
engineer
can
add
technical
research
needed
for
a
deal.
Ii
British,
you
don't
wait:
okay,
cool.
E
D
A
Research
on
other
teams,
I
just
started,
calling
it
a
research
issue,
I've
even
named
issues
like
spike
research,
and
then
you
can
tell
like
my
evolution
of
calling
issues,
research
issues
over
they're
all
named
different
and
whatever
we
want
to
call
them
I'm
totally
cool
with.
We
can
call
them
technical
evaluations
like
I,
don't
have
I
have
no
like.
We
can
avoid
the
research
issue
altogether.
A
D
Yeah
I
think
that's
a
good
call
out
just
to
just
sort
of
indicate
like
like
there's
a
lot
of
research
that
happens
right
like
we
have
like
future
research.
We
have
UX
research,
we
have
like
engineering
research
and
that's
like
an
overloaded
term.
So
if
we
can
just
create
like
distinct
terms
that
can
use
and
like
mentally
map
them
as
separate
things,
I
know,
we
talked
about
research.
D
Spikes
in
the
past
for
engineering,
like
you
know,
like
let's,
let's
sort
of
just
pick
some
some
names
and
then
be
consistent
about
it,
so
that
we
know
like
this.
One
is
about
UX,
and
this
one
is
about.
You
know,
feature
design,
and
this
one
is
about
engineering
and
then
having
that
naming
will
make
it
really
easy
to
look
at
something
in
sick,
okay.
This
needs
some
engineers.
C
D
E
I'm,
just
out
of
some
notes
here,
while
reading
the
page
I'm,
mostly
I'm,
missing
more
details
on
how
US
contributes
to
this
process
and
I
think,
especially
with
the
blen
face,
we're
like
Oh
XP
am
an
engineer.
Anders
here
define
how
I
work
and
I
had
a
point
about
needing
developers
to
groom
things
and
then
Jackie
already
responded
that
front
end.
It's
Nathan
back
end
is
Shawn
yeah
we're
these
management
right
and
I
keep
ending
my
next
question.
It's
also
know
it's
kind
of
related,
so,
for
example,
for
the
hsm
don't
require
problem
social
validation.
E
It
would
be
nice
to
have
some
sort
of
acceptance
criteria.
That's
designs
need
to
be
ready
before
it
moves
to
planning
breakdown,
so
kind
of
related.
You
need
D
arise
there
and
not
just
the
designs
or
the
proposal
attached
to
it
and
Jackie's
typing.
Yes,
move
back
to
e
to
design
and
just
some
other
observations,
like
kind
of
linked
to
water,
references
in
the
handbook,
so
that
we
don't
repeat
content
and
also
we
already
do
this.
E
But
it
would
be
nice
to
keep
the
UX
designer
scientists
to
develop
into
the
development
issue
when
there
is
a
change
in
UI,
especially
so
that
you
know
who
to
tag.
Or
you
know
that,
so
you
have
to
review
something
when
there's
an
emerging
West
open
and
you
don't
have
to
wait
for
it
being
from
the
developer.
So
just
general
observations
and
then
Sean.
You
know
the
last
something
very.
B
Quickly
are
now
really
at
a
time,
so
if,
for
example,
I'm
working
on
a
on
the
bus
issue
and
I've
noticed
some
problems
in
the
in
the
documentation,
so
I'll
do
a
small
motor
quests
on
that,
but
should
I
should
that
be
then
labeled
like
release
group,
even
though
it's
you
know
an
engine
on
top
of
that,
should
it
actually
have
a
milestone
assigned
to
it.
So.
A
I'm
cool
with,
if
you're
gonna
deliver
it
in
a
milestone
because
I'd
want
it
to
count
toward
your
mrs
right
as
a
that's
a
def
metric.
So
we
need
to
get
that
in
the
milestone
and
yes,
adding
group
label
and
category
label
and
if
it's
related
to
our
bug
or
a
feature
that
would
be
awesome
because
I'll
have
to
triage
the
issue
anyway,
because
the
Box
gonna
send
it
to
me
and
be
like
hey.
You
don't
have
a
category
on
this.
Please
assign
it
so
I'll
end
up
doing
it.
Anyways
well,.
B
D
We
don't
have
dashboards
on
it,
though
we
might
I,
know
you'll
major
ones
right
now,
but
we
will
but
yeah
I
track
it
to
your
group
and
then,
if
it's,
you
know
like
whatever
type
of
work,
it
is
if
it's
a
feature,
a
bug
backstage
or
security.
I
think
we're
that
are
the
main
categories
of
those
following
performance.