►
From YouTube: Digital Experience Iteration Retro 2021/03/25
Description
Sprint Retro Doc: https://docs.google.com/document/d/1kMNiUF2UDuSrMDuzLyRi8OEhVxry_MJoYi38RmmWafY/edit?usp=sharing
Digital Experience handbook page: https://about.gitlab.com/handbook/marketing/inbound-marketing/digital-experience/
Inbound Marketing handbook page: https://about.gitlab.com/handbook/marketing/inbound-marketing/
A
Hello,
everyone
and
welcome
to
the
digital
experience
sprint
retrospective
for
this
release
cycle
march,
and
it
is
the
25th
today
so
we'll
start
off.
Are
we
starting
off
with
things
that
went
well,
I
guess
I
said
that
so
that's
what
we're
doing
so,
yeah,
I'm
not
sure
who
wrote
this
first
item,
but
if
you
did,
please
speak
up.
B
That
was
me.
I
forgot
to
put
my
name
things
that
went
well
for
me.
Was
intern
online
cross-team
collaboration
with
the
events
templates.
I
felt
that
people
responded
quickly
with
quick
decisions
and
proactive
problem.
Solving.
There
was
very
little
need
to
manage
expectations.
C
And
yeah
we
have
ongoing
conversations
about
our
grid
system.
A
happy
accident
where
we
discovered
tailwind
kind
of
does.
C
We
needed
to
do
out
of
box,
so
that's
great
and
I'm
glad
that,
like
javi
and
anyone
else,
who's
involved
in
great
discussions
was
able
to
kind
of
align
with
me
on
that,
and
I
think
sung
me
here
up
next.
D
Okay,
thank
you
so
this
week
one
of
the
things
that
went
super
well
for
me
is
my
first
template
and
templating
experience
on
ruby
and
thanks
to
tyler
he's
the
one
that
has
been
hoping
that
this
will
come
to
person
yeah.
I
think
it's
coming
I
on
personal
projects.
I
still
don't
think
I'm
gonna
be
using
ruby,
but
now
I
think
I'm
feeling
comfortable
working
my
way
around
and
doing
what
I'm
doing
so
that
actually
went
well
and
thanks
to
everyone
that
has
been
working
on
that
stack
for
a
very
long
time.
D
D
E
Other
jay
yeah
I
just
want
to
shout
out
lauren
for
leading
our
latest
get
101
class.
It
was
awesome,
love
your
enthusiasm
always
and
ever
so
slowly,
beginning
to
understand
gitlab.
F
Okay,
I
just
wanted
to
shout
out
that
our
code
reviews
have
gone
a
lot
better,
like
I
think
the
quality
of
our
the
feedback
that
we
give
each
other
has
gone
way
up,
at
least
like
since
we
started
here.
So
I
would
encourage
us
to
continue
like
that
trend
because,
like
I
think
like
when
I
first
came,
I
like
didn't
know
what
to
look
for,
and
I
think
like,
as
we've
gotten
like
a
groove
and
more
comfortable
with
each
other.
It's
like
easier
for
me
to
say
like
this
is
good.
F
G
The
blog
post
template
deployment
went
well
and
the
slack
announcement
helped
by
giving
places,
people
can
add
direct
feedback
that
needs
to
happen
right
away
and
for
future
iterations
and
everyone
hopped
in
and
it.
G
A
Cool,
so
I
guess,
unless
laura
wants
to
vocalize
that
little
note
below,
we
can
go
on
to
the
things
to
improve
on
for
next
sprint
cycle,
and
it
looks
like.
F
Javi's
up
first
yeah.
This
is
kind
of
a
little
bit
related
to
like
this
bigger
point
that
I
think
some
of
you
all
have
put
in
the
in
the
things
to
improve
on
like
in
your
own
sections,
but
like
I
think
I
see
this
issue
like
more
so
like
when
I'm
actually
trying
to
publish
npm
where
it's
like,
if
we're
on
version,
0.7.4
and
two
people
are
working
on
things
concurrently
like
who
gets
to
get
like
the
0.5
bump
and
sometimes
like.
F
If
let's
say
this
is
something
that
happened
where
it's
like,
and
this
is
like
totally
like.
There's
no
way
to
know
like
like
tyler
was
working
on
something
because
he
was
like
trying
to
leave
before
friday
and
like
I
was
also
working
on
something
on
friday
and
like.
I
think
we
started
using
like
the
alpha
tags
like
differently,
so
we
both
had
like
different
alpha
versions
of
like
the
same
thing,
and
so
then,
when
we
went
to
the
full
version,
it
was
just
like
oh
shoot.
F
So
then
what
I
had
to
do
like
after
he
was
gone,
like
was
essentially
like,
say
like
all
right.
Like
I'm
version
this
like
this
is
zero
7.6,
for
instance,
and
he
alright
and
then
tyler's
version
are
0.7,
and
then
I
have
to
make
like
a
0.7.8
that
has
both
of
our
changes
and
so
like
stuff
like
that
was
just
annoying.
F
The
rebase
was
like
crazy
because
it's
like
you
have
to
find
like
in
what
order
do
you
want
like
the
things
to
be
like
brought
in,
and
so
that
was
a
pain
in
the
butt.
We
should
find
a
better
way
to
deal
with
that.
Another
thing
that
I
have
on
my
next
point
right
here.
I
actually
have
three
points:
wow.
F
Okay,
point
number
two
is
just
like:
how
do
we
go
about
backlogging
stuff,
I
think
like
saw
me
in
the
beginning
of
the
sprint,
was
like
I'm
not
really
sure
what
to
work
on,
and
I
feel
like
it
makes
sense
to
like.
F
I
don't
know
like
improve
that
process
like
a
little
more
and
I
don't
know
what
that
would
look
like,
and
I
don't
know
what
suggestions
people
have
for
that,
but
just
like
in
my
head,
it's
like.
F
F
So
that's
like
what
I
have,
and
I
see
people
writing
comments.
If
people
want
to
jump.
A
Yeah,
so
I
think
in
terms
of
how
to
how
to
prioritize
the
work
part
of
that
is
during
the
sprint
planning
like
we
know
that,
there's
stuff
coming
in,
we
know
that
there's
stuff
we
want
to
do,
and
we
can
all
you
know
talk
about
what
projects
we
propose
that
we
work
on
that
sprint.
Obviously
that
doesn't
help
the
things
that
are
in
the
backlog.
So
it's
it's
kind
of
going
to
be
a
discovery
process
of
how
we
can
do
that
moving
forward,
but
there's
always
going
to
be
too
much
to
do.
A
G
I
am
have
a
couple
epics
that
I've
was
talking
michael
with,
and
that
happened
this
one.
G
What
do
you
guys
think
about
adding
these
epics
or
issues
to
our
sprint
doc
so
that
we
all
know
that
they're
there
and
then
we
can
choose
issues
from
them
like
every
before
every
sprint.
Like
oh,
hey,
everyone,
we
should
probably
be
looking
at
these
things,
yeah
you
don't
have
to,
but
just
okay
yeah.
I
think.
C
Yeah,
I
think
I'm
always
like
combing
through
my
past
history
and
like
links
and
whatever
trying
to
find
which
okr
tickets
and
stuff
yeah
having
a
single
source
of
truth
would
be
awesome.
And
then,
if
we
want
to
do
work
that
fits
within
one
of
those,
we
can
create
issues
within
those
epics
and
they're
easy
to
find.
Yes,
love.
A
F
Sweet
and
then
very
quick,
last
point
like
in
my
head-
I
I
don't
know
I
was
thinking
about
this
earlier
today
is
like
people
are
gonna
like
stumble
onto
slippers
and
like
be
like.
What's
this
like
what
is
all
this
code
stuff
like?
What
does
this
mean
to
me
like?
I
feel
like
that.
We
should
have
like
an
entry
point.
That's
not
so
like
so
tied
to
understanding
how
code
works.
So
it's
like
people
can
like
just
like
consume.
F
It
understand
the
concept
and
like
if
they
don't
necessarily
care
how
it
works
like
they
don't
have
to
know
we
we
we
can
have.
I
know
there's
like
a
lot
of
different
ways
to
go
about
it,
but
that's
just
something
that
I
wanted
to
bring
up.
If
anyone
has
like
points
on
that,
I.
F
H
Well,
I
was
gonna,
say
well,
you
may
or
may
not
know
and
like
we
did
a
little
run-through
of
figma
last
week
and
then
we
have
storybook
and
then
we
have
tailwind
like
they're
in
and
of
the
same
thing.
So
I
think
it
would
probably
be
a
good
idea
to
align
on
a
video
to
just
to
get
people
to
understand
like
it's,
not
just
like
michael
kind
of
pointed
it
out.
H
If
we
just
did
a
video
on
figma,
it
would
make
it
look
like
that's
all
we're
producing,
which
is
just
a
couple
of
graphics
and
figma,
which
is
not
really
just
not
really
the
case
at
all.
So
it'd
be
a
great
idea,
I
think,
to
align-
and
we
don't
have
to
do
at
this
point.
But
whenever
they
say
like
this
is
all
in
the
one
thing,
but
it's
just
three
different
torch
points
and
how
this
team
outputs
productivity,
and
so
I'm
not
just
showing
them
in
isolation.
So
we
talk
about
storybook
and
isolation.
H
F
C
Yeah
kind
of
related
to
your
versioning
problems,
it's
just
specifically
in
slippers.
If
I
have
one
or
two
mrs
open
and
then
something
gets
merged
in
my
other.
Anything
that
I
have
open
has
merge
conflicts
and
it's
just
that
compiled
css
and
the
compile
javascript
or
like
yeah.
If
you've
added
a
new
package,
then
your
package
json
is
going
to
be
a
conflict
which
is
fine.
It's
just
a
matter
of
like
you
know,
checking
out
each
branch,
rebasing
or
running
a
yarn
build
or
whatever
like
getting
it.
C
You
know
into
a
state
where
it's
all
up
to
date,
it's
just
a
pain
to
do
that.
We
don't
really
need
to
be
committing
those
compiled
files
because
they
get
rebuilt
on
merge
and
on
release
kind
of
thing.
So
maybe
if
we
add
them
to
a
git
ignore
or
whatever
you
know
like
some
sort
of
way
to
just
like
nope,
we
don't
commit
these
like
thousand
line
gobbledygook
files
that
can't
even
be
viewed
in
gitlab.
You
know
in
the
interface.
C
So
if,
if
that's
an
improvement,
we're
all
kind
of
aligned
on
it
might
be
worth
doing.
D
Yeah,
I
think
the
git
you
know
will
be
very,
very
important.
I
think
lauren.
I
think
you
spotted
that
on
my
present
made
request
about
some
css
files,
that
is
in
the
disk
folder
which
shouldn't
be
compiling
over
and
over
again.
So
I
think
we
should
improve
on
that
area
because
I
sense
the
same
problem
happening
to
me
too.
C
Yeah,
sweet
and
one
other
thing
I
wanted
to
just
go
back
when
javi
was
talking
about
the
npm
version
in
conflicts,
brandon
and
tommy.
You
made
some
good
points
about
maybe
doing
like
an
actual
release
cycle
like
having
a
day
that
we
release
or
something
and
just
we
merge
everything
into
master
and
then
do
like
a
release
at
some
point
when
we
call
all
kind
of
a
line
on
it,
but
or
or
at
least
some
sort
of
communication
around
who's
releasing
what
version
that
might
be
helpful.
C
If
we
can
figure
out
a
way
to
do
that,
but
yeah
cool
lauren
you're
up
next.
G
I'm
just
piggyback
on
your
your
comment
on
8b
there's
always
going
to
be
conflicts
and
dub
dub
dub.
So
I
made
a
quick
video
this
morning
because
there
were
other
conflicts
that
hanif
was
encountering
and
this
isn't
really
documented
in
a
great
form
for
anyone
using
dub,
dub
dub.
So
let's
make
that
better
for
everyone,
I'm
I'm
I'm
pretty
spicy
in
my
video,
so
I
should
yeah
make
like
a
doc,
okay,
nine.
What
is
the
requirement
to
announce
an
mrs
complete
and
ready
for
deployment?
G
I
put
what
I
do,
but
I'd
like
to
hear
from
from
y'all
what
that
is.
A
I
mean
I,
I
kind
of
go
along
with
what
lauren
outlined
and
then
also
there's
the
mr
checklist,
that's
mentioned
in
certain
temp
blitz.
I
think,
and
we
have
a
handbook
page
on
it.
So
I
might
add
that
item
to
her
list
of
things,
but
that's
that
tends
to
be
more
of
a
this-
is
a
larger
thing.
There's
two,
I
think
I
made
two
template
versions
of
that
where
one
is
like
a
shorter
list
and
one's
a
longer
list,
but
it
also
it's
not
just
the
code
right.
A
It
also
covers
things
like
is
this
content
inclusive
and
you
know
other
other
things
that
speak
to
company
values.
So
it's
it's
always
good
to
remember
to
go
over
that
checklist
as
you're
making
those
merge
requests.
D
C
One
of
the
pieces
of
functionality
that
I've
seen
in
the
gitlab
ui
that
I
haven't
used
is
yeah.
If
you
have
merge
requests
that
you've
opened
and
you
kind
of
go
back
and
forth
and
you
make
changes
and
people
are
commenting
and
everything
is
changing.
And
then
you
hit
a
point
where
you
think
it's
good,
but
maybe
everyone
else
that
was
commenting
and
reviewing
has
kind
of
forgotten
about
it
or
they
don't
know
that
you're
ready.
C
There
is
like
a
little
request:
re-review
like
a
little
arrow
beside
their
name
as
a
reviewer
or
whatever.
So
like.
I
don't
know
what
that
does.
I
assume
it
like
pings
the
person
like
emails
them
and
says
like
please
look
again
or
whatever.
So
I
don't
know
if
we
utilize
that
I
haven't,
I
haven't
had
huge
big
pieces
yet.
G
For
the
blog
post,
I
had
to
use
that
at
least
once
probably
should
have
done
it
more
because
that
there's
like
15
updates
so
and
I
want
someone
to
actually
check
it
after
I've
done
all
those
updates
before
I
launch
it,
because
I
almost
deployed
it
and
updated
the
entire
release
blog,
which
would
have
been
super
bad
and
like
that
was
like
final
seconds
like.
Oh,
no,
don't
do
that
yeah,
it's
nice
to
get
eyes
on
it!.
F
I
had
like
a
a
quick
question
that
just
like
escaped
me:
I'm,
like
it's
gonna,
bother
me
now
but
like
we'll,
keep
going
I'll,
let
you
know
if
the
question
comes
back.
F
I
remembered
I
remembered
I
remembered
okay,
so
I
know
you
all
were
gonna
talk.
Someone
was
gonna,
talk,
okay,
wait!
So
notifications
like
how
do
you
all
have
your
notifications
set
up
within
like
the
gitlab
interface,
because,
like
I
think
right
now,
I
have
like
all
emails
turned
off
and
I
have
like
this
weird.
F
G
Yeah
there's
inconsistencies,
I
have
all
the
emails
sent
and
then
I
have
a
folder
in
my
gmail
that
funnels
all
the
notifications
and
I
look
through
it
every
morning,
every
lunch
every
evening
and
it's
like
100
200,
sometimes
and
then
I
have
to
select
them
all,
delete
it
and
it's
just
like
a
quick
visual
way
to
like
search
through
everything,
not
great.
But
it's
helped
me
because
I
don't
get
that
to
do
pain
every
time
either.
A
And
you
can
always
create
email
filters
too,
in
gmail,
like
basically
you
know
say
if
it's
app
mentions
me
then
put
it
in
this
folder
or
if
it's
you
know
from
so,
and
so
put
it
in
this
folder
and
mark
it
as
read
or
you
know,
whatever
you
want
to
do,
there's
there's
ways
to
filter
in
gmail,
which
is
nice
to
have
that
extra
layer
of
notification.
A
Cool
any
other
thoughts
on
that
item
should
we
move
on.
We
can
always
async
on
that
later
too.
So
I
think
I'm
up
next
and
kind
of
similar
to
what
javi
and
jess
were
noticing
about
initials.
Earlier
I've
worked
with
lauren
for
like
two
years
now,
and
I
guess
I
just
never
saw
our
initials
next
to
each
other,
so
like
lb
and
bl,
like
you,
know,
kind
of
like
one
typo
away
from
missing
the
person's
name,
but
anyway
fun
little
thing
I
just
noticed
so
yeah.
A
I
just
wanted
to
remind
us,
because
this
happened
to
me
this
sprint-
that
seemingly
small
tasks
can
snowball
out
of
control
into
larger
ones.
So
just
a
reminder
for
us
all
to
add
buffer
time
to
our
projects.
We
don't
actually
know
how
long
things
are
to
take
so
yeah.
That's
always
good
to
know,
and
I
think
tina's
up
next.
B
Next
then,
it's
it's
pretty
much
the
same
as
what
brandon
just
said.
I
didn't
account
for
time
spent
on
tasks
that
weren't
actually
related
to
my
boards
or
my
issues
or
my
epics,
so
supporting
the
blog,
for
example.
So
it's
a
good
reminder
to
under
commit
so
that
you
have
capacity
to
help
the
the
rest
of
your
team
and
to
support
your
team
on
other
things.
E
So
I'm
just
continuing
the
conversation
from
the
end
of
our
ui
to
code
meeting
about
how
we
want
to
hand
off
design
to
development
in
terms
of
an
mr
or
an
issue
and
who's
in
charge
of
creating
that
in
the
everyone
was
there,
so
I
don't
think
laura
or
sami.
Was
there
maybe
others,
but
the
consensus
at
the
time
was
like
mr
was
preferred,
but
then
there
was
like
an
issue
that
showing
up
on
the
board.
So
I
wasn't
sure
if
that
was
gonna,
be
like
a
blocker
for
us.
E
If
we
still
needed
an
issue
just
for
tracking
purposes
and
how
far
in
advance
you
guys
would
like
notice
if
at
all
or
just
like
it's
done,
do
it.
G
I
will
offer
my
opinion.
We
need
to
have
the
engineering
issues,
so
we
can
attach
the
mr
to
it,
so
it
shows
up
on
our
engineers
boards.
I
don't
like
that,
but
I
don't
see
any
way
to
get
the
mrs
actually
on
our
boards
at
this
time.
B
And
I
think
also
having
conversations
about
changes
in
the
amr
is
the
preference
for
engineers
and
then
using
the
issue
to
be
like
this
is
done,
reviewed
closed
or
having
less
conversations
in
the
issues.
More
conversations,
yeah
like
the.
G
B
C
I
also
like
the
idea
of
having
an
issue
for
like
just
have
the
source
of
the
the
figma
files
and
stuff
that's
yeah,
assigned
to
an
engineer
opening
an
mr.
It
means,
if
I'm
understanding
this
correctly.
The
mr
would
be
like
open
the
entire
time
that
the
end
work
was
also
happening,
and
I
don't
know
now,
there's
like
an
mr
that's
open.
That
is
the
design
and
then
an
mr
that
the
engineer
has
created,
or
it's
all
one
mr
kind
of
thing
there's
no
mmr
for
design,
there's
only
one.
E
Confusion
around
when
we
hand
it
off.
Are
you
guys
going
to
be
just
doing
an
mr
or
you.
E
Issue
attached
and
like
how
much
notice
do
you
want
that,
like
the
design
work
is
going
to
be
ending
soon
or
like?
Do
you
want
to
know
at
the
beginning
of
the
project
that
we're
working
on
that's
now
in
like
two
three
weeks
or
maybe
a
month
from
now,
you
might
have
this
on
your
plate
or
you're,
just
cool
with
being
like
okay,
we
finished
this
thing
yesterday.
Now
it's
yours
do
what
you
will
like
that's
the
kind
of
stuff
I'm
looking
for.
H
D
I
think,
from
my
perspective,
I
would
prefer
just
an
mr
for
for
engineers,
because
I've
seen
that
my
conversations
have
been
splitted
all
around
scattered
all
around.
I
have
some
conversation
on
the
mri.
D
I
have
some
conversation
on
the
issue
for
engineer
and
I
have
another
conversation
on
the
issue
for
design,
so
I'm
reading
through
three
different
threads,
but
I
can
eliminate
the
three
just
to
just
just
two
one
single,
mr
for
engineering,
where
I
can
have
all
my
discussion
related
to
that
and
if
I
still
need
to
know
anything
about
the
design
part,
I
can
go
back
into
that
issue
and
look
through
so
instead
of
creating
another
extra
issue
for
me,
so
I
can
handle
every
discussion
for
engineering
just
in
the
mr.
D
So
at
the
time
when
the
design
is
ready,
we
can
just
anybody,
can
open
an
mr
and
assign
it
to
anybody.
So
I
think
that
can
be
a
very
small
standing
over
from
design
to
engineering
so
for
based
on
what
jesse
is
saying
that?
Okay,
what
if
the
mr
is
not
something
we
should
work
on
right
now,
yeah
then
it
can
still
be
there
for,
like.
Maybe
a
couple
of
weeks
before
we
start
work
on
that
right
thing,
I
don't
think
engineering
issue
is
necessary.
I
think
it's
causing
more
confusion.
D
F
So
I
know,
becky
was
looking
into
other
features
that
we
can
use
in
git
lab
issue
templates
that
we
ended
up
not
using
for,
like
the
whole
inbound
marketing,
I'm
interested
to
see
if
we
would
be
interested
in
use
like
looking
into
some
of
those
ourselves
to
see,
if,
like
maybe
there's
ways
for
us
to
like
be
creative
about
like
instead
of
having
like
the
idea
of
like
we
have
an
engineering
issue
and
then
a
design
issue.
F
A
So
I
I
will
add
kind
of
my
experience
on
that
is.
As
an
engineer,
I
want
one
final
document
starting
point.
I
don't
want
to
have
to
sort
through
all
of
the
prior
conversations
so
like
if
we
have
one
artifact
it's
great
to
have
that
one
artifact
be
the
single
source
of
truth,
but
then,
when
I
have
to
read
through
all
of
that
to
get
to
what
I
need
and
so
part
of
the
things
that
have
happened
in
the
past
is
like.
Okay,
that
makes
sense.
A
We
could
solve
that
by
putting
the
final
bit
of
information
that
the
engineer
needs
in
the
issue
description.
Well,
then,
someone
comes
along
and
doesn't
know
that.
That's
where
the
final
information
needs
to
be
and
they're
having
more
conversation
and
then
goals,
change
and
shift
and
the
updated
description
never
happens.
And
so
then
you
don't
know
right,
and
so
personally
I
like
to
have.
A
This
is
where
the
engineering
is
starting
and
all
private
prior
discussions
can
continue
to
be
ongoing.
But
like
this
is
this
is
the
non-shifting
deliverable
that
I
have
and
then
I
can
review
later.
So
so
that's
how
it
kind
of
ended
up
where
it
is
in
my
head,
but
that's
not
to
say
we
have
to
continue
that
way.
It's
just
something
to
be
aware
of,
as
we
have
these
conversations
moving
forward.
G
I'd
like
to
piggyback
on
that
specifically
for
the
events,
commit
template
one
or
maybe
a
couple
issues
for
tina
that
if
that
is
going
to
turn
into
an
epic
for
engineering
with
20
30,
separate
engineering
issues,
so
that
won't
be
a
one-to-one
use
case.
F
Yeah,
I
think
that
makes
sense.
I
guess
like
in
my
head,
there's
like
not
like
a
one
at
least
I
record
I've
seen
there's
like
a
size
fits
all,
but
I
think
it's
just
more
so
like
communicating
like
what
do
we
do
in
that
case,
for
instance,
and
like
how
does
our
team,
especially
when
issues
are
flowing
within
us,
I
think
sometimes
we
may
run
into
issues
when
we
start
communicating
with
outside
parties,
but
I
think
just
like
for
us
to
have
like
an
alignment,
I
think
would
make
us
a
lot
more
efficient.
F
So
that's
good.
That
could
be
an
action
item.
A
Good,
so
I
think.
C
Did
we
land
on
we're
gonna
be
doing
issues?
I
don't
know
if
or
did
we
land
on
we're
gonna
keep
talking.
E
C
G
F
A
Sounds
like
we,
we
got
to
a
point
where
we
we
know
what
to
do
for
that
now
moving
forward
and
we
can
continue
to
discussion
and
iteration
after
that,
so
yeah.
I
think
that
out
covers
our
our
retro.
Today
we
have
a
few
action
items
here
that
we
have
already
discussed,
but
if
we
want
to
just
kind
of
recap
them
really
quick,
so
it
looks
like
we
should
file
an
issue
for
merge,
conflicts
and
slippers.
A
You
know
and
investigating
what
we
want
to
do
with
that
and
add
a
list
of
epics
and
issues
to
our
sprint
planning
dock,
which
is
a
good
idea.
We
all
kind
of
very
enthusiastic
thumbs
up
on
that,
and
you
know
to
do
to
look
into
project
management
for
issues,
and
you
know
how
we
want
to
do
that,
how
we
can
iterate
on
that
to
improve
things
moving
forward
and
looks
like
jess
is
yeah
and
and
kind
of
the
conclusion
of
what
we
just
talked
about
as
well
with
design
handoffs.