►
From YouTube: UX Showcase - Managing my UX capacity
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
Hi,
I'm
vithika,
I'm
the
senior
product
designer
for
the
pipeline
execution
team
and
today
I'm
going
to
talk
about
managing
my
ux
capacity
so
to
be
able
to
deliver
maximum
values
for
our
work
as
designers
who
are
working
for
a
complex
product,
we
need
to
prioritize
the
items
that
we
work
on.
We
need
to
switch
through
a
lot
of
context
very
regularly
and
even
need
to
continually.
You
know,
learn
from
our
past
mistakes
and
keep
improving
as
we
go
on
and
planning
helps
us
to
just
that
now.
A
During
my
time
here
at
gitlab,
I've
tried
and
tested
and
even
experimented
with
so
many
different
ways
for
planning
my
quarterly
and
even
my
milestone,
work
and
today.
I
think
that
I'm
in
a
position
where
I
can
say
that
I
have
a
lot
better
clarity
around
what
I'm
doing
and
how
I'm
managing
my
workload.
So
in
today's
presentation,
I'd
mostly
be
running
you
through
the
evolution
of
my
planning
process
over
time.
A
Okay.
So
where
did
I
begin?
So
this
is
the
epic
that
I
first
started
to
use.
This
was
around
more
than
a
year
ago
and.
A
How
it
what
I
would
use
to
work
with
I
started
off
working
like
I
would
manually
add
to
a
table
all
the
design
issues
that
I
plan
to
work
on
in
a
given
milestone,
and
I
had
to
go
and
look
for
issues
with
a
certain
set
of
labels
on
the
git
lab
project
and
make
sure
that
all
the
items
that
I'm
putting
here
in
the
tables
they
stay
updated
at
all
times,
and
this
was
doable
until
there
was
a
requirement
that
I
worked
for
two
groups.
A
So
there
was
a
time
when
I
was
kind
of
handling
work
for
both
the
ci
as
well
as
pipeline
authoring
group.
And
if
luckily,
I
found
an
issue
that
also
kind
of
gives
a
peek
into
how
scary
the
situation
was
so
like
you
can
see,
there
was
a
huge
number
of
issues
that
were
being
worked
on,
and
it
was
kind
of
getting
very
difficult
for
me
to
manually,
keep
a
track
of
everything
and,
at
the
same
time,
keep
on
updating
things.
And
while
these
things
were
happening,
there's
also
kind
of
a
confusion
like.
A
When.
Should
I
be
removing
issues
from
this
epic,
and
when
should
I
be
adding
issues
to
this
epic?
So
I
decided,
after
having
a
conversation
with
my
2
pms
and
my
manager,
that
this
was
getting
too
much
to
handle.
So
I
would
rather
work
with
the
planning
issue
for
the
stage
group,
because
it
was
also
kind
of
observed
that
there's
a
disconnection
between
my
own
planning
and
my
team's
planning-
and
it
was.
A
It-
was
only
a
better
way
to
work
that
I
start
participating
in
the
stage
group
planning
instead,
so
making
this
transition
was
interesting
along
with
the
engineering
planned
work,
we
started
to
have
a
ux
fan
work
section
here
in
this
issue
and
what
this
did
was
it
exposed
certain
flaws
in
our
process,
so
continuous
integration,
which
is
now
pipeline
authoring,
it's
a
mature
stage
group.
So
we
need
some
critical.
I
mean
we
get
some
critical
infrared
issues
on
a
regular
basis
and
they
are
hardly
ever
planned.
A
That
was
the
difficulty
I
was
facing,
and
I
had
no
ground
to
like
put
my
foot
down
and
say
that
this
is
my
limit,
because
I
was
unable
to
even
calculate
my
limit
in
this
situation
now
hannah,
who
had
very
recently
transitioned
as
my
manager
around
that
time.
She
took
notice
of
few
things
that
I
was
myself
not
able
to
observe
around
that
time
and
she
helped
me
navigate
through
my
planning
process.
Asking
me
many
questions
along
the
way,
and
that
was
also
the
quarter.
A
I
think
where
we
were
focusing
on
career
growth
and
development,
so
I
figured
that
the
first
thing
I
need
to
do
is
get
my
priorities
in
order
and
set
a
scope,
division
goal
for
myself
and
that's
where
I
took
pedro's
help,
and
that
was
very
patiently.
He
took
me
through
through
his
own
process,
how
he
prioritizes
his
commitments
and
that's
when
I
came
up
with
this
table.
A
So
I
like
try
to
understand
like
what
are
my
key
priorities
or
targeted
responsibilities
and
then,
what's
my
current
time
of
division,
and
where
is
it
that
I
want
myself
to
like
what
is
it
that
I
want
to
achieve?
How
what
changes
I
have
to
make
and
what
should
be
the
trajectory
like?
How
should
I
move
towards
that?
So
now
I
had
a
clear
picture
of
where
I
was
headed,
and
I
also
was
aware
of
the
challenges
that
I
had
to
get
through
from
my
previous,
like
experiences.
A
So
the
key
challenges
that
I
kind
of
observed
on
the
way
was.
I
should
be
keeping
the
system
lightweight
and
easy
to
communicate
lightweight
because
it
shouldn't
take
me
a
lot
of
effort
to
just
go
in
and
feed
the
information,
so
it
should
be
easy
to
maintain
as
well
then
maintain
an
ssot,
because
now
I
was
everywhere
like
if
I'm
taking
care
of
a
couple
of
stage
groups.
A
I
am
probably
participating
in
both
the
planning
issues
and
eventually,
I'm
also
having
to
keep
another
document
just
to
keep
a
track
of
all
the
items
that
I've
worked
on
a
milestone
because
things
are
so
scattered
all
along,
so
maybe
a
better
method
to
maintain
in
ssot
and
at
the
same
time,
I
thought
that
I
should
also
be
flexible,
because
there
are
many
different
responsibilities
that
come
along
the
way
it
shouldn't
be
that
my
structure,
my
process
is
so
rigid
that
it
just
couldn't.
A
It
makes
it
very
difficult
to
make
room
for
any
unanticipated
work
that
shows
up
and
then
calculating
velocity.
So
this
was
taking
a
hard
hit.
It
was
very
difficult
for
me
to
understand
how
much
is
it
that
I
can
take
up
in
a
milestone
or
even
like
what
it
thinks.
When
should
I
start
telling?
A
No,
and
that
was
really
important,
because
I
was
ending
up
overworking
myself
then,
apart
from
all
of
this,
it
was
also
very
important
for
me
to
align
with
my
pm's
process
because
we
have
to
work
in
tandem
when
it
comes
to
a
team.
A
So
that's
when
I
started
working
on
my
plan
for
q2
and
q3-
and
this
is
like
I-
I
just
put
a
very
rough
structure
here,
and
this
was
later
translated
into
something
better
like
I
moved
this
set
of
information
in
a
different
way
to
some
milestone
issues
which
I'll
get
to
after
some
time
now,
when
jackie
took
over
as
an
interim
pm
for
pipeline
execution,
she
proposed
to
bring
in
an
old
method
that
she
had
been
using
in
the
release
team
with
hannah
before
and
that
was
to
use
an
epic
to
track
all
the
activities.
A
All
the
active
design
work
in
the
stage
group.
So
we
made
a
shift
in
the
working
style
here
and
instead
of
assigning
milestones
for
development
work.
First,
the
issues
are
now
added
to
this
epic
first,
and
once
we
get
the
design
work
done
only
then
it
is
moved
to
it
is
assigned
any
milestone
and
move
to
planning
breakdown
when
it
is
weighed
by
the
developers.
A
So
design
is
always
ahead
of
development
by
default
with
this
method,
and
that
that's
what
I
really
like
about
it
now,
you
may
ask
that
what
happens
to
the
forward-looking
concept
so
based
on
the
user
inputs
that
we
get
and
also
inputs
from
marketing
our
essays.
Our
terms,
we
keep
aside
a
generous
bandwidth
for
research,
every
milestone.
A
So,
besides
tackling
problems
in
a
very
reactive
way,
we
also
make
sure
that
we
are
working
on
some
value,
adding
and
even
value
enhancing
proposals,
and
this
this
literally
took
away
from
me
the
responsibility
to
keep
a
vigilant
eye
on
the
triage
issues
and
regularly
look
out
for
any
change
that
might
happen
on
any
of
the
planned
issues
because
it
was
getting
just
too
difficult.
A
There
are
so
many
different
labels
that
were
used
and
even
when
one
label
goes
away,
it
gets
very
tricky
if
I
should
be
looking
at
the
issue
or
should
I
be
like
removing
it
from
my
backlog,
but
this
epic
in
itself
it
was
very
transient.
I
mean
it
solved
a
lot
of
problems
for
me.
Yes,
but
it
it
wasn't
itself
very
transient,
because
items
come
here
and
the
moment
the
workflow
design
phases
over.
I
put
the
workflow
planning
breakdown
labels
on
those,
and
then
they
go
away
from
this
epic.
A
So
it
made
it
difficult
to
track
the
velocity
again
and
keep
a
track
of
capacity
and
even
keep
a
record
of
all
the
milestone
work
that
I've
been
doing.
So,
let's
say,
if
I'm
working
too
fast,
and
I
don't
even
have
an
idea
about
how
many
issues
I'm
taking
up
in
a
milestone
and
for
that
hannah
made
a
really
good
suggestion
that
for
creating
milestone,
design
planning
issues.
A
So
I
pick
up
items
from
this
epic
and
I
plan
to
work
that
I
plan
to
work
on
in
a
given,
milestone
and
add
them
to
respective
milestone
issues.
Now
at
first
it.
It
appears
like
this
is
too
much
of
work,
but
this
has
actually
been
very
like
beneficial
for
me
in
many
ways
and
I'll
get
to
it.
So
I
also
add
works
from
other
stage
groups,
because
there
are
times
when
I
am
also
supporting
different
stage
groups,
for
example
in
14.1
and
14.2.
A
I
kind
of
I'm
supporting
project
quality
like
the
testing
team,
with
the
project
quality,
dashboard
solution,
validation
exercise,
so
that's
also
accounted
for
and
along
with
that,
if
I
write
any
blogs
or
do
any
kind
of
illustrations
or
any
side
work,
all
the
ux
okr
works.
They're
all
accounted
for
in
these
milestone
issues
now
yeah.
So
it
took
me
about
a
couple
of
months
to
recalculate
my
capacity.
Even
while
I
was
working
with
this
process,
but
this
is
the
closest
I
have
ever
been
to
being
successful
in
this
effort.
A
My
scope
is
flexible
enough
now,
and
I
mean
by
flexibility
I
mean
I
can
include
work
from
all
different
sides
to
this
issue
and
I've
kind
of
included
many
different
examples
for
a
milestone
issue,
because
I
started
off
with
like
experimenting
again
and
over
time.
I
have
been
able
to
realize
like
what's
my
capacity
and
where
could
I
reduce
time?
A
What
could
I
take
away
to
make
room
for
something
that
shows
up,
for
example
like
in
this
milestone,
since
I
am,
I
have
some
onboarding
buddy
duties
while
on
boarding
gina
to
the
testing
team,
so
I
reduced
my
capacity
for
stage
work
from
20
to
15,
and
similarly
this
was
the
research
bandwidth
was
brought
down
from
15
to
six.
A
So
it's
easier
for
me
to
understand
and
keep
a
track
of
like
what
becomes
less
and
where
can
I
make
compromises
so
coming
back
to
the
challenges
now,
yes,
I
have
an
ssot,
which
is
the
milestone
issues.
It
has
information
from
all
different
sites,
all
at
one
place,
and
it's
very
easy
for
me
to
communicate
with
my
product
manager,
with
my
ci
cd
ux
design,
teammates
with
my
manager
and
also
with
my
engineering
teammates.
A
So
everybody
is
able
to
look
at
what
is
it
that
is
occupying
me
in
a
given
milestone
and
they
understand
what's
happening
there
and
it's
also
very
lightweight,
because
what
I
do
is
like.
I
have
a
pretty
good
idea
about
how
much
I
can
accommodate,
so
I
once
this
is
done
like
then,
whatever
is
being
added
to
this
epic.
Apart
from
the
active
issues
I
can
like,
I,
I
can
see
that
this
is
what
I'll
be
working
on
in
the
next
to
next
milestone,
because
it's
in
my
epic
it
is
strategized.
A
So
that's
where
it
goes,
and
then
it
is
totally
aligned
with
my
pm's
process
and
it's
very
smooth
and
I'm
totally
able
to
keep
like.
I
have
a
full
control
over
my
capacity
in
this
way
and
that's
all
there
are
a
couple
of
reads
that
I
found
very
interesting
online
and
I'll
be
adding
these
links
to
the
document
as
well,
but
yeah.
That's
it.
B
This
is
awesome.
Thank
you
for
sharing
your
process
with
us.
Then
I
have
a
read-only
item,
but
if
you
want
a
voice,
feel
free
to
do
that.
C
Yeah
just
want
to
say
thank
you
so
much.
This
was
so
interesting
for
for
me
for
us
right
now,
and
I've
just
dropped
a
link
in
there
to
to
an
issue
which
which
links
to
a
google
sheet,
where
we've
across
the
team
have
gathered
kind
of
how
we're
doing
milestone
planning
at
the
moment,
if
we're
doing
it,
and
some
of
the
challenges
around
that
I'd
love
to
talk
more
about
this.
So
thank
you
so
much
for
for
sharing
this.
This
is
really
interesting.
B
I'm
super
happy
to
see
like
the
story
right
that
you
put
together
around
it,
and
I
think
I
know
figuring
out
your
x
capacity
is
hard,
and
I
think
especially
for
us
that
well
now
everyone
is
working
remotely,
but
when
you
come
from
a
non-remote
environment
and
you
have
to
figure
out
how
to
collaborate
with
people
understand
the
product
understand
your
capacity,
how
you
work
it's
hard
and
I've
been
I've
been
through
that
myself,
and
I
think
that
you
mentioned
a
lot
of
key
elements.
B
You
know
to
figuring
out
that
capacity
like
being
more
strategic
when
collaborating
with
your
team
being
part
of
planning
process
planning
issue,
I
think
I'm
not
sure
how
things
are
going
on
with
other
teams,
but
sometimes
you
see
that
yeah
designers
are
not
included
in
the
in
the
workload
for
what
the
the
release
gonna
look
like
that.
That
should
be
the
default
right
and
recording
that
keeping
the
receipt
for
what
the
ux
capacity
and
the
effort
is.
B
I
think
it
also
helps
us
to
say
no,
when
we
are
doing
right,
not
a
lot
not
too
much,
but
when
we
are
at
capacity,
and
I
have
very
strong
opinions
about
this
topic,
I
linked
here
a
comment
in
a
thread
that
I
had
the
conversation
had
with
nick
post
about
balancing
designer
the
more
senior
roles,
and,
in
my
experience
I
think
it
gets
easier
when
your
counterparts
are
also
thinking
working
strategically,
and
I
see
that,
for
example,
a
lot
in
what
pedro
does
and
how
he
organizes
his
work.
B
A
B
Nadia
you're
up
next.
D
Yeah
thanks
so
much
for
sharing
this,
because
this
is
super
interesting
and
I
understand
the
struggle.
I've
gone
through
a
very
similar
process
as
well
and
also
landed
on
using
the
planning
issues.
For
for
this,
though,
I
don't
really
use
our
weighting
scale,
so
I
was
wondering
how
do
you
ensure
you
accurately
assess
the
issue
weight
and
do
you
often
find
yourself
having
to
move
issues
back
to
problem
validation
or
just
not
engage
in
like
active
design,
because
there's
so
many
open
questions
or
like?
D
What's
your
process
for
actually
getting
those
issues
weighted.
A
Right
so
this
also
touches
upon
a
very
recent
problem.
We
faced
in
pipeline
execution
that
there
were
some
items
which
were
so
like
so
complex
that
the
moment
they
got
into
workflow
design
phase.
A
We
started
to
uncover
problems
that
we
had
no
idea
about
and,
like
it
went
into
a
rabbit
hole
of
discussion
again,
so
we
made
a
change
to
the
handbook,
I'm
not
able
to
find
it
right
away,
but
I
will
definitely
share
the
link
on
this
document
and
that
change
says
that,
just
like,
we
create
a
spike
issue
in
the
development
like
when
there's
a
development
happening
for
having
discussions
which
were
not
anticipated
and
we
need
to
time
box
it.
A
Similarly,
we
should
treat
like
the
discussions
that
happened
in
the
design
phase
in
a
similar
way
like
create
spikes
and
immediately
change
the
label
and
change
the
assignee,
because
if
the
designer
doesn't
have
a
sole
control
over
what's
happening,
they
shouldn't
be
assigned
and
they
shouldn't
be
like
accountable
for
that
delay
and
as
long
as
it's
the
question
of
understanding
like
what's
the
right
weight,
there's
a
learning
that
there's
a
never-ending
learning
on
that.
A
So
it
just
goes
on,
but
I
think
now
I'm
able
to
understand
better
like
how
to
it
has
improved
over
time.
It
is
not
as
inaccurate
as
it
used
to
be,
but
it's
not
perfect.
Yes,.
D
That
makes
sense.
Thank
you.
I
think
it
makes
a
lot
of
sense
this
this
new
addition
that
you
had
to
the
to
the
handbook
to
change
the
dri.
Now
it
got
me
thinking
that
this
is
how
we
treat
mars
when,
when
ux
is
doing
a
review
on
nmr
they're
assigned
as
a
reviewer,
so
we
keep
track
of
that,
but
we
don't
really
do
that
when
we
are
having
the
discussions
with
the
engineers,
so
that's
it.
I
just
found
the.
D
B
E
Yeah,
thank
you,
vithika,
I'm
very
happy
to
see
where
you
are
today
compared
to
our
conversation
that
we
had
some
some
months
ago
and
that
you're
feeling
you're
in
a
better
place
and
very
happy
for
you
and-
and
I
completely
understand
the
feeling
of
I.
E
This
is
the
closest
I've
been
to
you
know,
freeing
this
out
and
I
feel
like
I'm
there
and
that's
how
I
feel
every
day
at
good
lab,
but
I
always
know
that
this
is
probably
not
gonna
last
long
and
we
always
have
to
keep
adapting
right,
but
but
anyway,
very
happy
for
this
presentation.
E
The
question
I
have
is,
what
do
you
think
are
the
advantages
and
if
you
have
time
to
talk
about
the
disadvantages,
but
mostly,
what
do
you
think
are
the
advantages
of
using
those
planning
tracking
issues
where
you
have
tables
with
with
your
issues
and
and
the
weights
and
all
of
that
versus
doing
that
in
in
an
issue
board.
For
example,.
A
So,
first
of
all,
I
think
for
an
issue
board.
I
need
to
have
all
the
issues
on
the
same
project
right
and
that
was
again
a
problem
for
me,
because
I
was
I
wanted
every
different
thing,
that's
being
worked
on
in
different
projects
to
be
accounted
for
in
at
one
place,
and
I
also
make
this
the
planning
issue
itself,
a
part
of
the
epic
that
that
jackie
is
looking
at.
So
everything
is
like
very
in
very
close
proximity
and
yeah.
That's
mostly,
I
I
couldn't
answer
like.
A
What's
the
like
showstopper
reason
that
I'm
using
this
over
boats,
but
since
I
am
looking
at
including
everything,
that's
like
that-
that's
probably
not
even
an
issue,
because
sometimes,
for
example,
right
now,
I'm
working
on
some
ci
permission,
audit
work
and
most
of
my
work
is
happening
over
spreadsheets.
A
E
Yeah
yeah,
I
so
issue
boards.
You
can
create
them
at
the
group
level
as
well
and
you
can
create
them
at
the
level
of
the
gitlab
org
group
and
it
will
work
for
any
project
yeah.
What
I've
personally
been
more
interested
in
is
is
issue
boards,
because
we
can
add
the
design
weight
labels
and
you
can
create
issues
like,
for
example,
you
were
talking
about
your
onboarding
experience
that
you
will.
You
will
have
to
support.
I.
E
I
would
imagine
that
in
my
case,
I
would
assign
myself
to
that
issue
and
try
to
have
it
visible
in
my
board.
But
what
I
did
like
about
your
approach
with
the
issue
is
that
it's
easier
for
you
to
add
notes
and
maybe
have
a
conversation
just
focus
on
ux,
because
usually
those
conversations
about
planning
happen
for
me
happen
either
in
the
issues
themselves
or
in
the
group
planning
issue
which
contains
engineering
and
all
of
that.
But
it's
not
necessarily
bad
because
we
can
have
threads
yeah.
C
A
So
definitely
something
I
can
explore,
but
this
last
point
you
pointed
it's
something
I
did
not
take
into
account,
but
that's
definitely
helping
you
because
I
usually
have
conversations
with
hannah
and
jackie
over
those
issues.
If
I
take
something
out
or
if
I
decide
not
to
proceed
with
something,
that's
where
I
let
them
know.
C
B
And
I
had
a
comment
here:
I
think
the
tri
bars
in
the
past.
I
think
that
dimitri
was
a
strong
user
of
boards
for
doing
his
planning
and
having
issues.
What
I
learned
and
what
I
also
saw
happening
with
vitica
with
her
previous
pm,
is
that
something
changed
order
in
a
board,
so
they
stack
rank
right
and
they
prioritize
by
the
order.
And
how
do
you
tell
the
designer
that
the
priority
change
right?
B
You
have
a
label,
but
you
might
forget
to
update
the
label
and
what
happens
with
fitika
and
and
jackie
is
that
they
communicate
about
when
something
enters
her
epic
or
enters
her
planning
issue
and
there's
always
a
comment.
There's
always
a
history
that
you
can
follow
and
you
see
the
story.
You
see
the
receipt
rather
with
the
blending
boards
yeah.
Anyone
can
change
the
order
and
if
they
don't
communicate
that
it's
it
becomes
a
mess
and.