►
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
Come
to
the
livestream
of
iteration
office
hours,
we're
trying
to
help
collectively
think
through
how
we
can
break
things
down.
Iteration
is
one
of
the
six
core
values
that
get
lap
and
it's
the
toughest
one
and
chun
zhen.
Do
you
have
the
first
run?
Thanks
to
that,
you
want
to
verbalize
a
bit.
What
what
yes.
B
B
One
of
the
reasons
is
because
of
the
contacts
which
at
because
there
suddenly
their
high
priority
tasks
came
in
and
our
team
members
had
to
switch
to
the
heralded
tasks
and
left
some
issues
in
the
middle,
and
that
way
it
was
slipped
from
that
release.
I'd
like
to
get
some
opinion
or
your
insight
on
how
do
we
handle
breaking
down
issues
or
take
an
iterative
approach?
Well,
there
may
be
some.
A
I
think
the
the
idea
is
to
break
down
things
as
much
as
possible
and
and
if
the
tasks
are
smaller,
you're
less
likely
to
get
interrupted
in
this
case,
I
don't
see
how
this
task
could
have
been
made.
Smaller
and
I.
Don't
see
how
the
s1
issue
really
looks
like
an
urgent
issue,
and
so
I,
don't
I
think
what
happened
happened
here,
I
think
in
general.
What
we're
trying
to
do
by
making
things
smaller
is
to
reduce
the
chance
that
you
get
interrupted.
A
If
you
work
on
a
three
week
three
week
task,
the
chances
that
you'll
it
will
get
interrupted
is
three
times
greater
than
if
you
run
on
a
one-week
task
same
for
any
size.
So
that's
what
we
try
to
make
tasks
smaller
than
the
chance
of
every
individual
task.
Getting
interrupted
is
smaller
and
also
if
it's
smaller,
there's
less
it's
quicker
to
spool
back
up
after
you
switch
the
contact,
there's
less
contacts.
If
for
smaller
tasks,.
C
So
SS
one
might
not
be
the
situation
where
you
kind
of
just
go
and
drop
everything
on
the
floor.
If
you
are
close
by
there
is
something
to
be
said
about.
If
you
correctly
scope
down
the
issue,
you
can
give
a
good
estimate
of
weddings
going
to
be
completed.
So
if
an
s-1
is
actually
really
an
s-1
that
needs
to
be
handled
immediately,
you
can
always
ask
how
long
does
it
take
to
wrap
up
the
ongoing
issue
before
you
continue
further
and
if
it's
called
properly.
A
But
looking
at
the
issue,
it
seemed
pretty
urgent,
so
that's
s1
is
s1.
Otherwise
it
should
have
been
a
nest.
You
cool,
okay,
thank
you,
but
I
agree
like
if
you
have
the
chance
just
talk
with
the
person
requesting
met.
You
have
the
next
one.
Thanks
for
putting
something
on,
you
want
to
verbalize.
It
sure.
D
Yep,
so
my
question
is
partly
about
the
actual
feature,
but
more
about
the
process
we
took
in
breaking
it
down
and
I
work
with
the
metrics
dashboards.
We
wanted
to
add
a
new
feature
to
allow
for
annotations.
We
started
with
an
issue
that
was
just
kind
of
do
the
work,
but
change
it
to
be
this
issue
that
I've
linked
here
to
spike
issue
to
come
up
with
a
more
iterative
approach,
so
we
broke
the
feature
into
iterations
and
then
added
issues
underneath
for
the
implementation,
starting
with
kind
of
an
API
approach,
then
building
on.
D
So
it's
still
in
progress
but
I
feel
like
we
took
a
fairly
iterative
approach
and
some
of
the
team
members
highlighted
it
in
our
retrospective
that
they
like
this,
but
I
want
to
know
if
there's
feedback
on
doing
this
kind
of
let's
plan
it
out
first
and
break
it
all
down
approach
of
doing
that
or
as
an
alternative,
you
know
just
starting
with.
Let's
do
the
first
thing
we
know,
let's
see
how
that
goes,
and
then
figure
it
out
kind
of
what
the
next
step
is.
After
we
do
the
first
day,
yeah.
A
C
So
the
way
I'm
looking
at
this
issue,
without
actually
digging
into
every
single
piece,
is
you
named
first
iteration,
and
it
has
five
items
in
there
from
there
I
don't
see
how
they
actually
rate
related
to
each
other,
as
in
I
would
name
the
first
iteration
basic
implementation
of
of
the
crowd
right.
That
will
give
you
enough
path
forward
to
enable
a
feature
for
people
to
use
it
in
their
own
way,
and
then
the
second
iteration
would
be
understanding
how
they
use
it.
C
If
they're
using
and
if
you're
they're
not
using
it,
then
you
can
talk
about
what
is
on
your
roadmap.
What
do
you
actually
want
to
accomplish,
and
that
would
be
your
second
iteration,
so
without
going
into
all
of
this
together,
I
would
say
the
first
iteration
is
actually
number
one,
not
first
iteration
group
of
five
things
and
then
get
feedback
from
that
and
figure
out.
Whether
number
three
is
even
gonna
come
to
you
in
this
sequence.
It
might
be
in
what
you're
calling
now
a
third
iteration.
Is
it
go?
No.
A
Few
remarks
and
then
all
the
comments
we
give
are
not
necessarily
about
the
specific
examples.
Just
a
way
to
get
our
brains
working
I
think
it's
super
useful
to
have
a
vision
where,
as
house
is
gonna
end
up
in
in
some
time
and
think
through
that
thinking
is
much
cheaper
than
faster
than
programming.
So
it
helps
you
see
around
corners,
I
I'm,
not
a
big
fan
of
them
planning
out
every
iteration.
You
only
have
to
plan
the
first
thing,
I'm
pretty
sure.
A
A
So,
that's
that
that's
a
bit
weird
to
me
I
understand
that
when
you
have
that
vision,
you
think
like
I'm,
going
to
plan
everything
out
to
get
there
I
think
that's
an
anti-pattern
and
some
of
the
things
here
were
API
first
I
think
API
last
is
better
and
this
might
be
something
to
even
write
in
our
engineering.
Docs
api's
are
very
hard
to
change.
There
are
a
contract
with
the
people
programming
towards
our
interface,
so
you
should
build
api's
when
you
have
as
much
information
as
possible.
A
So
after
as
many
iterations
as
possible,
then
you
expose
the
API
not
at
the
start,
because
now
you're
locked
into
that
design,
so
I
I
think
I'd
get
like.
We
should
be
an
API
last
company
nan
an
API
first
company,
though
I
know
that's
much
more
trendy,
but
I
think
our
API
should
be
stable
and
api's
are
hard
to
change.
The
last
thing
was
something
I
noticed
like
there
was
already
a
plan
to
kind
of
deprecated
annotations
after
two
weeks,
I
was
super
sad.
A
If
I
made
in
a
manual
annotation
in
get
lab
and
in
two
weeks
later
was
gone.
So
maybe
that's
just
for
the
automated
annotations,
but
it
seems
a
bit
like
a
maybe
we
could
even
we
like
how
big
of
a
workload
our
annotations
gonna
be.
Is
that
really
needed?
It
seems
it
seems
like
getting
ahead
of
ourselves
a
bit
maybe
monitor
whether
they're
really
getting
a
problem
starting
to
be
a
problem
instead
of
doing
that
automatically.
A
E
A
Well,
you're
making
decisions,
not
just
that
you
can
create
an
annotation,
but
also
how
you
can
create
what
data
do
you
need
to
send
and
it
could
be
for
sample
that
in
the
beginning,
you
you
want
to
color
and
suppose
you
want
to
call
her.
You
made
the
decision
like
I'm,
going
to
do
colors
in
RGB,
but
you
talked
with
people
and
it
it
turns
out
that
every
that,
if
you
do
it
in
RGB,
it
doesn't
work
with
if
people
change
color
schemes.
A
C
A
A
A
You,
even
even
if
you
do
a
time
stamp,
you're
gonna
walk
in
onto
like
how
many
milliseconds
you
accept
in
the
time
step
like
examples
are
just
for
illustration.
It's
probably
not
true,
but
I.
It
locks
you
in
and
so
I'd
be
hesitant
to
have
an
external
contract,
because
if
it's
an
internal
contract,
where
you
have
both
sides
of
the
equation,
you
can
iterate
much
faster
than
when
it's
with
an
unknown
number
of
external
parties,
which
is
an
application
programming
interface.
So.
F
One
strategy
I
have
seen
used,
and
so
you
can
feel
free
to
disagree
with
this,
but
one
strategy,
I've
seen,
is
the
fact
that
you
said
crud
to
start
with
and
you're
doing
all
four
of
those
operations
just
doing
the
create
one
makes
it
pretty
clear
to
customers
that
we're
still
experimenting
with
this
API
and
it
kind
of
gives
them
a
better
idea.
So
if
there's.
F
No
way
you
just
stored
a
like
I
thought
about:
okay,
a
friend,
a
friend,
just
a
friend
display
where
it's
temporary,
where
you
can
do
annotations
personally,
might
be
a
solution,
but
it's
not
it's
ephemeral
right
so,
like
you,
don't
have
an
API
in
that
situation,
but
at
least
gives
customers
view
of
it.
So,
if
you're
up
against
the
clock-
and
you
want
to
give
customers,
visibility
and
annotations
with
no
storing
of
that
data
with
the
the
way
to
go-
that's
non
API.
First
from
that
respect,
that
was
an
example.
The.
F
F
H
There's
also
the
case
of
like
a
lot
of
the
stuff
that
we're
doing
now
is
graph
QL
first,
which
is
like
our
new
API,
and
so
we
don't
want
to
build
it
outside
of
graph
QL
and
they
bring
it
in.
So
maybe
would
it
make
sense
to
kind
of
mark
some
things
as
experimental
and
not
officially
part
of
the
API
yeah.
H
A
H
Like
I
think
that
that
makes
sense
too,
because,
as
you
use
the
API,
you
discover
the
the
problems
with
it,
but
obviously
with
something
like
graph
QL.
If
you
using
the
Explorer,
it
might
be
difficult
to
know
what
is
sort
of
the
official
API
and
what
we're
just
kind
of
using
to
pass
information
to
the
front
end.
While
we
get
the
API
right
and
I,
don't
know
if
we
have
a
way
of
marking
that
kind
of,
but
generally
as
a
way
of
iterating,
it
does
make
sense
to
you
to
make
the
API
official.
I
So
it's
really
good
I
think
it's
really
gonna
depend
on
the
type
of
end-user.
My
experience
tells
me
that
enterprise
users
are
way
more
youth
to
change
in
a
TI's.
This
is
why
they
use
versioning
and
all
that
and
also
their
heavy
consumers
of
API.
So
to
me,
that's
frustrating
to
go
to
a
service
and
not
find
a
way
in
which
I'm
doing
something
enterprise
level
that
I
have
to
go.
Click
and
click
I
mean
this
is
my
windows
on
the
data
center.
A
Years
ago,
Sophie
for
I,
don't
think
is
ever
going
to
change
from
fee.
For
so
we
are
not
really
versioning
our
API,
so
change
is
hard,
so
I
think
maybe
instead
of
saying
API
last,
it
should
be
API
experimental
first,
like
you
first
mark
something
as
experimental
to
indicate
that
it
might
change
I.
Think
that's!
That's,
maybe
a
better
way
to
achieve
it,
because
I
kind
of
agreed
like
it's
it's
kind
of
unfair
to
not.
A
E
Something
important
here
which
we're
kind
of
dancing
are
not
really
naming
which
is
api's,
are
very
strategic
and
we
may
need
an
AP
at
a
driver
front
dent,
but
like
Jerry's,
indicating
enterprise
users
may
have
additional
or
different
expectations
and
Twitter
famously
got
into
a
you
know.
They
broke
the
entire
web
one
day
when
they
end-of-life
their
v1
API,
and
the
story
behind
that
is
they
had
this
culture
at
the
time
or
anybody
kind
of
ship
anything
so
developer.
E
Just
wrote
an
API,
it
was
built
to
power
their
front
end,
and
the
moment
people
saw
that
API
they
looked
at
it
and
just
jump.
The
collusion
of
oh
I
could
build
a
Twitter
client.
So
that's
what
they
started
doing
right,
but
Twitter
later
came
to
the
strategic
conclusion
of
all
these
Twitter
clients
are
actually
detracting
from
our
business.
We
have
to
shut
it
down
and
then
then
the
API
became
v2,
which
was
not
just
a
new
version
of
the
API.
E
It
was
the
data
firehouse
right
and
that
was
used
by
hedge
funds
to
do
trading.
It
was
a
totally
different
use
case.
So
I
do
think
we
had
like
does.
Does
an
API
that
is
is
used
to
power
our
front
end?
Is
that
strategic
for
us?
Is
it
useful
for
people
to
build
another
front
end
for
us,
or
should
we
be
doing
something
I?
Don't.
A
I,
don't
think
anybody's
doing
that
and
Twitter
encouraged
people
making
other
clients
they
refer
to
clients
they
put
in
there
but
interface.
What
client
you
were
using,
so
that
wasn't
an
accident
that
people
started
building
quite
straight.
Our
clients
was
just.
He
got
a
bit
scared
when
one
smart
investor
started
rounding
up.
All
the
different
quit
Twitter
clients
got
like
was
on
track
to
get
the
majority
of
the
Twitter
traffic
and
threatened
to
split
off
into
another
Twitter
that
he
would
name
something
else.
That
is
one
day
got
super
super
concerned.
A
They
bought
the
biggest
Twitter
client
and
they
started
with
the
Twitter
medallions,
where
you
needed
a
medallion
to
start
a
new
client.
So
it
wasn't
accidental.
It
was
a
very
strategic
move.
I,
don't
think
we
have
the
same
problem
with
other
people.
Do
the
interface
if
I
think
our
analogy
is
much
more
like
something
like
Jenkins,
which
exposed
a
ton
of
api's
to
plugins
and
it
fixed
them
in
place
where
they
couldn't,
where
it's
very
hard
to
change
the
software,
because
you
were
constrained
by
so
many
api's
and
our
mission
is
everyone
can
contribute.
A
So
the
most
important
thing
is
that
the
software
is
malleable,
that
you
can
keep
changing
it
and
api's
kind
of
have
this
outside
constrain
and
the
more
constraints
you
have,
the
harder
it
is
to
to
move
and
keep
improving
your
software.
So
the
more
api's
are
experimental,
the
more
we
can
break
as
we
need
to
change
our
software
I
think
that's
the
the
bigger
picture.
E
G
That
was
a
really
good
conversation.
Ok,
where
am
I
now,
actually
one
of
the
things
that
Matt
said,
I
think
applies
to
my
situation,
which
is:
do
we
iterate
on
what
we
know
first,
so
this
issue
started
off
as
a
front-end
issue.
If
they
didn't
need
back
in
support
and
as
time
went
on,
they
discovered
they
do
team
back
in
support
when
backing
got
involved.
Now
we're
kind
of
restarting
the
investigative
stage
and
there's
a
lot
of
collaboration
back
and
forth
long
story
short.
G
It
ended
up
slipping
twice
when
back-end
did
make
some
changes
and
I
think
that
they
I
think
both
front-end
and
back-end
iterated
well
in
their
merger
quests,
but
when
back-end
did
submit
the
change
that
caused
more
problems,
and
now
we
have
unknown
things
that
we
didn't
think
about
and
kind
of
that
story
where
it
spiraled
out
of
control.
So
I
wanted
to
get
your
thoughts
on
outside
of
small.
Mrs,
how
could
we
have
iterated
in
this
case
the
collaboration,
the
unknown
problems
and
things
like
that?
Yeah.
A
Let's,
let's
dive
into
it,
because
this
on
the
surface,
it
seems
like
this
super
simple.
She
I
have
the
same
thing
like.
Oh,
this
seems
simple,
just
ask
her
API
to
request
the
file
and
just
show
the
fowl
like.
What's
what's
hard
about
this,
what
what
did
people
run
into
what
what
what
made
it
hard
yeah
I
can
talk
about.
J
It
I'm
sure
if
you
want
so
basically,
we
noticed
that
we
had
the
endpoint
to
get
the
data
from
the
file
and
the
full
file
was
used,
but
it
missed
one
particular
aspect
which
is
the
detail
of
the
viewer
that
we
use
for
the
kind
of
renamed
file.
So
it
was,
we
had
an
endpoint
for
the
file,
but
it
was
missing
parts
of
that
endpoint
that
we
totally
missed
when
we
were
planning
and
then
when
we
were
building
it.
J
J
A
Once
they're,
just
just
thinking,
was
there
a
way
to
kind
of
display
the
file
ugly
or
something
like
that,
just
open
it
in
Brawl
just
offer
the
customer
instead
of
saying
file
moved
and
displaying
it.
It's
saying:
there's
file
moved,
there's
displaying
it,
but
an
in-between
option
is
just
make
it
a
link
that
so
you
can
open
it
in
the
raw
whew.
J
G
We
did
consider
from
the
backend
perspective
is,
and
why
do
we
need
to
call
it
a
rename
file?
Why
can't
we
just
display
it
like?
We
display
all
files,
but
that's
kind
of
where
the
problem
lies,
because
it
could
be
an
image.
It
could
be
a
text,
it
could
be
different
things.
We
need
to
handle
the
diff
differently
for
the
scenarios,
but
obviously
linking
to
a
file
would
have
made
all
of
those
irrelevant.
Yeah.
A
I
think
that's
the
like.
That's
the
80/20,
like
the
person
just
wants
to
see.
Okay,
what
happened
here
and
right
now,
it's
like
there's
no
link!
It
will
cost
you
two
minutes
to
find
it.
That's
exaggerating,
but
just
making
that
easier,
so
kind
of,
and
that's
just
kind
of,
if
it's
too
hard
to
make
just
let's,
let's
let's
change
plan
and,
let's
think
about
what's
even
easier
to
me,.