►
From YouTube: Digital Experience Team: Boards Workshop
Description
Notes are here: https://docs.google.com/document/d/1jcDZtZpCXsJfF03HEXF5BUfLwtUGJUsReclIvGAVdeE/edit#
A
Okay
hi:
this
is
the
digital
experience
team.
We
are
just
talking
about
boards,
how
they've
been
working
to
date,
really
great
conversation,
we're
specifically
making
this
video
for
you
becky
just
so
that
you
can
get
insight
into
what
we're
talking
about
things
that
we
think
have
worked
things
that
we
think
could
go
better
and
some
potential
ideas
how
to
move
them
forward.
A
A
We
think
that
there's
because
our
project
lives
nested
within
the
www,
the
main
problem
that
we're
all
working
around
is
we
can't
easily
work,
mr
first
and
allow
all
the
awesome
get
lab.
Project
management
features
to
work
the
way
they
should
so
it's
creating
a
little
bit
of
extra
work.
Like
you
know,
we
have
to
have
an
engineering
issue
and
then
an
mr
and
things
get
lost,
so
we're
we're
aware
of
that.
We
know
that
that's
no
one's
fault
for
setting
it
up
that
way
and
are
hoping
that
you
know
in
a
near
future.
A
State
when
we
eventually
get
to
own
the
double
dub,
dub,
dub
repo-
and
you
know,
split
it
off
from
the
handbook,
we'll
be
able
to
see
some
big
gains.
But
in
the
meantime
we
just
wanted
to
talk
through.
What's
been
going
on
some
things
that
we
think
we
can
do
better.
So
I'll
share
my
screen-
and
this
is
just
going
to
be
sort
of
no
real,
no
real
plan
here-
we're
just
going
to
go
through
this.
So
why
don't
we
get
going
into
what
works?
I
see
avi
you're,
kicking
it
off.
B
Yeah
something
that
works
well
for
me
personally
is
when
I
bookmark
the
boards
to
the
browser.
It
helps
me
keep
track
of
things.
I
realize
that
if
I
don't
do
that,
I
won't
ever
look
at
my
own
boards
or
I'll
just
lose
where
they
are
on
a
related
note,
something
I
like
about
the
ports
features
is
that
when
I'm
working
with
labels,
you
can
assign
a
board
to
have
like
a
ton
of
labels
out
and
essentially
when
you
create
an
issue
from
that.
From
that
view
it
adds
those
labels
automatically.
B
So
I
don't
have
to
like,
create
an
issue
and
then
add
all
the
labels.
I
don't
know
if
that's
something
that
we
were
supposed
to
know,
but
that's
something
that
I
really
like,
because
I
I
forget
all
the
time
what
labels
to
use
in
what
context,
so
just
having
a
system
where
I
don't
have
to
think
about
what
labels
to
use
is
really
beneficial,
and
I
can
explain
that
further,
but
I
think
we
all
get
the
point.
B
I,
like
the
label
that
I
created
for
the
web
design
system
just
because
I
personally
for
myself,
I
wanted
to
keep
track
of
all
the
things
that
we
are
doing
across
two
different
repos,
which
is
inbound
marketing
and
slippers,
which
is
really
nice,
yeah
tyler.
C
Yeah,
I
you
know
coming
from
being
a
developer
on
a
marketing
team
elsewhere.
The
thing
that
works,
like
I
love
having
issues
be
like
my
primary,
like
lawrence
of
the
agency
day,
work
these
external
requests.
It's
awesome
as
a
developer
like
actually
getting
an
issue
for
a
web
page
things
that
I
have
in
the
past,
fielded
as
emails,
slacks
or
dri-fi
conversations
at
a
cubicle.
C
So
I
think
that
like
using
boards
for
for
these
external
requests
are
great
and
I
think,
to
some
degree,
the
like
I'm
kind
of
like
having
said
with,
like
the
labels
and
the
templates,
I
think
those
are
useful
for
that,
especially
when
it
comes
to
managing
information
requirements
and
especially
just
like
the
documentation
and
the
handbook
first
async
kind
of
stuff.
So
I
love
it
for
these
external
requests
in
the
agency
day,
work.
A
I'm
just
adding
here,
I
think
one
thing
that
did
work
well
is
when
they
work
and
we're
able
to
it's
the
right
kind
of
work.
That's
coming
in.
It
ensures
we're
only
taking
on
an
appropriate
amount
of
work
per
week.
A
It
gives
it
gives
our
teammates
and
our
leaders
an
opportunity
to
look
at
our
boards
and
say
hey
like
love
that
you
love
being
here,
love
that
you
want
to
do
a
ton
of
stuff.
You
should
only
have
you
know
eight
to
ten
weight
points
this
week
and
I
notice
you
have
16
those
numbers.
A
A
So
that's
great
yeah.
I
think
I
think,
there's
a
lot
of
positives.
I'd,
also
interject
to
say
that,
like
I
know
we
in
a
previous
discussion,
I
know
a
lot
of
us
just
aren't
looking
at
boards,
because
there's
a
lot
of
things
that
can
be
improved.
So
why
don't
we
jump
into
what
doesn't
work?
A
Brandon?
I
see
her
at
first
there
and
if
there's
any
comments
on
the
side
on
stuff
too,
like
feel
free
to
jump
in,
if
you
made
the
comment
to,
I
think
there's
some
really
good
conversation
going.
There.
E
Yeah
sorry,
I
just
kind
of
shoehorned
this
item
in
there
we
were
talking
earlier
and
reviewing
some
of
these,
and
I
didn't
mention
this,
but
it
popped
into
my
head
that
some
of
the
problems
we've
run
into
before
is
anyone
can
change
anyone
else's
boards
accidentally?
So
you
know
you
drag
an
issue
into
a
specific
sprint.
You
say
it's
assigned
to
me
I'll
be
working
on
it.
Someone
else
goes
and
changes
it
to
a
different
milestone
because
they're,
you
know
whatever
their
deadlines
are
like
it
doesn't
coexist.
E
C
And
yeah
my
the
the
biggest
thing
that
came
up
for
me
still
being
somewhat
new
here
but,
like
I
didn't
even
know
about
this
process,
and
it
just
wasn't:
it's
just
onboarding
right
and
I
think
that's
external
to
us.
I
think
that,
and
I
think
because
I
I
think
many
teams
managed
all
of
these
processes
differently.
C
I
didn't
this.
The
handbook
page
on
the
process
wasn't
a
part
of
my
onboarding.
I
didn't
like
know
how
this
was
going
on
and,
like.
I
still
am
kind
of
unclear
on
the
process,
because
I
feel
like
I've
had
to
like
I'm
like
learning
about
it.
As
I
go
and
they're
in,
like
I
don't
know
like
yeah,
I
don't.
C
I
don't
know
precisely
where
the
right
information
is
and
like
where
to
get
it,
because
there
are
a
ton
of
different
workflows
out
there
for
different
teams
and
like
searching
the
handbook,
it
can
be
challenging
to
get
signal
from
noise.
F
I
could
just
add
to
that
comment
on
the
side.
I
didn't
even
know
that
boards
existed
and
I'm
sure
part
of
that
is
that
it
wasn't
in
the
onboarding
process,
but
when
I
did
find
out
that
they
existed
like
four
months
later.
I
I'm
not
sure.
I
also
know
what
the
benefit
of
it
is
because
I
like
looked
at
it
and
it's
like
oh
look,
I
have
a
board
cool
and
then
I
kind
of
forgot
about
it
again.
B
Yeah,
I'm
jumping
in
I'm
not
sure
what
tags
I'm
allowed
to
use,
despite
they're
being
paid
in
the
handbook.
I
wrote
a
comment
on
the
side
on
what
the
word
triage
literally
means.
I'm
looking
at
jess's
comment.
It
says
the
definition
is
to
assign
degrees
of
urgency,
it's
to
figure
out
what
works
comes
first,
second
or
third,
laura
also
added
it's
unclear
what
that
process
looks
like
to
us,
so
I
just
wanted
to
shout
out
those
things
I
have
the
next
couple.
B
B
And
then
I'm
reading
my
last
point
here,
I
started
to
sync
my
boards
up
with
inbound
marketing.
Oh
gotcha,
the
boards
that
I've
created.
No
one
else
uses-
and
I
don't
think
that's
anyone
else's
fault,
because
I
don't
think
it
should
be
that
anyone
has
to
use
the
board
it's
more.
So
like
do
whatever
the
work
that
you
have
to
do,
and
then
the
boards
will
automatically
like
figure
out
how
that
work
gets
reviewed
and
completed,
etc.
So
I
don't
think
it
should
be
like
someone
is
managing
a
board.
F
Yeah-
and
I
have
the
next
couple
points
that
are
just
kind
of
confusion
around
how
dates
work
internal
agency
stuff
gets
assigned,
and
since
there
are
usually
a
lot
of
kind
of
key
players,
they
have
all
been
given
a
date
of
you
know,
february
5th,
as
the
due
date
and
so
have
I.
F
But
I
need
the
content
and
the
assets
and
the
ebooks
and
the
whatever
before
that
date,
so
that
I'm
now
like
running
around
and
chasing
people,
and
sometimes
the
dates
don't
line
up
with
one
of
our
internal
agency
friday
work
days.
So
that's
been
kind
of
tough
to
manage,
so
maybe
there
would
be
a
solution
where
springboard
dates
could
kind
of
adjust
based
on
which
piece
of
the
puzzle
needs
to
be
built
at
what
time?
I'm
also
fuzzy
on
milestones
versus
due
dates.
F
I
try
to
make
them
be
the
same,
but
I
see
them
diverge
sometimes
and
lastly,
the
sprint
boards
that
I
see
myself
in
show
fridays
friday
after
friday
after
friday,
but
like
within
those
weeks,
there's
no
real
distinction
between,
like
I'm
working
on
this,
I'm
blocked
on
this,
I'm
a
reviewer
for
someone
else's
code
on
this
so
like
having
those
swim
lanes.
We
just
don't
have
access
to.
So
I
don't
know
how
much
use
we
get
out
of
boards
that
just
show
kind
of
what
we're
doing
every
friday,
yeah.
C
I
want
to
there's
a
bunch
of
plus
ones
on
the
milestone
versus
due
date,
because,
like
I'm
also
confused,
I
think
something
that
gets
very
confusing
on
it.
For
me
is
that
they
change,
and
I
I
don't
know
when
or
why
they
change
like
it
seems.
Sometimes
it
seems
like
it's
the
beginning
of
the
week.
C
Sometimes
it's
the
end
of
the
week
other
times
it's
other
times
and-
and
I
like,
because
I'm
like
thinking
of
the
milestones
as
due
dates,
I
like
set
my
own
cadence
to
like
meet
that
milestone
and
then,
when
the
milestone
change,
if
it's
like
the
milestone
was
friday
and
then
on
thursday,
it
changes
to
to
the
next
week,
but
I
like
front
loaded
it
and
so
on
wednesday
and
thursday
I
was
working
on
it.
C
It
just
feels
like
I
had
the
rug
pulled
out
from
underneath
my
feet
and
I
was
like
oh,
I
was
really
moving
fast
towards
this
deadline,
but
now
I
have
a
whole
or
this
due
date.
Rather
and
now
I
have
a
whole
extra
week
to
do
it,
which
I
wish
I
had
known
on
monday,
tuesday
and
wednesday.
So
I
yeah.
I
think
that's
confusing
to
me.
E
Yeah
I
just
kind
of
along
that
train
of
thought,
and
I
know
this
isn't
necessarily
applicable
to
what
we
do
here
at
get
lab,
but
agile
theory,
overall
kind
of
says
that
a
sprint
is
a
locked
down
thing
when
you
start
it
and
after
that
point
it
shouldn't
be
able
to
be
modified.
So
like
that
way,
you
know
what
you're
producing
that
sprint.
You
know
what
you've
been
promised
to
deliver
and
what
can
be
delivered
and
those
kinds
of
things.
E
I
know
that
always
that's
an
ideal
world
and
not
something
that
is
necessarily
achievable,
but
it's
something
that
hasn't
really
appeared
to
be
the
case
at
get
lab.
You
know
it's
happens
from
time
to
time,
but
yeah
anyway,
so
food
for
thought.
There.
F
I'm
wondering
with
the
milestone
verse
due
date,
if
somebody
does
have
a
good
explanation
of
the
difference
and
because
a
couple
of
us
also
put
that
we
read
the
handbook
and
still
don't
understand
it.
If
there's
some
sort
of
to
do
from
either
our
team
or
from
another
team,
that
could
maybe
be
more
clear
on
what
it
is
not
just
for
our
sake,
but
for
the
whole
company's.
F
C
Excellent
and
as
you
also
mentioned,
it's
cool
that
milestones
move,
because
I
appreciate
the
flexibility.
I
think
it's
easy
to
think
about
like
the
things
that
are
challenging
about
it
but
like
it
is
also
very
nice
that,
like
there
seems
to
not
be
a
ton
of
you
know
bad
feelings
when,
when
those
dates
change,
I
think
that's
really
good,
but
back
to
other
challenges.
C
I
just
this
is
just
like
a
hang
up
for
me.
I
don't
know
like
I
feel
weird
putting
not.
We
like
some
of
the
issues
that
I'm
working
on
seem
entire,
like
very
unrelated
from
all
the
other
stuff.
That's
in
this
board,
and
I
feel
weird
putting
it
there
and
very
specifically
for
me,
like
I,
you
know
if
I'm
working
on
something
that
is
like
middleman
extensions
that
affect
the
whole
www
repo.
C
It
like
feels
weird
going
next
to
the
agency
day,
work
or
things
that
are
just
like
just
things
that
I'm
looking
at
or
maybe
just
lauren,
and
I
are
looking
at
yeah
it
just
it
doesn't
like
fit
for
me
like
putting
it
in
the.
C
I
just
want
it
at
the
top
level,
because
it's
about
that
repository,
so
I
think
some
of
the
existing
boards
and
the
internal
issues,
whereas
the
external
requests
for
agency
days
like
make
a
ton
of
sense
and
are
super
useful
to
me.
I
feel,
like
I'm,
adding
noise
to
a
board
about
stuff
that,
like
the
people
really
using
that
board,
don't
care
about
and
don't
want
to
see.
D
I'd
like
to
second
that
and
also
bring
notes
to
stuff
happening
to
the
repo
that
isn't
tracked
on
these
boards.
That's
really
important,
such
as
upgrading
to
ruby,
2.7
and
there's
tons
of
merge
requests
right
now
open
for
that
which
is
going
to
have
huge
impacts
on
everything,
and
it's
not
tracked
on
any
of
our
boards.
But
it's
it's
high
priority
for
gitlab.
G
Yeah
I'm
next,
I
think
everything
that
I've
jotted
down
here
has
already
been
reflected
I'll
just
go
over
it
anyways.
I
don't
really
know
how
to
use
my
boards.
Whenever
I
go
there,
they're
either
empty
irrelevant
overwhelming.
I
don't
really
know
how
to
manage
them
and
what
the
benefit
is
of
managing
them.
For
my
personal
workflow,
often
things
are
just
being
moved
around,
so
I
just
I
just
rely
on
issues
and
to
do's
to
do
my
work.
That's
really
all
I
had.
B
B
I
have
kind
of
not
been
doing
that,
and
so
it's
just
like
the
ones
that
they
that
happen
in
my
head
are
just
like
you
know.
I
better
hope.
I
remember
to
add
them.
Lauren
mentioned
one
that
I
thought
was
really
helpful.
That
could
be
helpful
for
me
is
to
add
them
on
the
one-on-one
docs
and
then
for
my
next
point,
do
you
ever
check
about
gitlab
issues?
Mrs,
I
don't
even
know
if
that's
something
that
we
do
is
that
something
that
we
should
be
doing?
B
D
Yeah
this
leads
nicely
into
mine.
Gitlab
works
best
when
merge
requests
are
created
from
issues
within
the
project,
repository
that
that
works
getting
done
and
we're
missing
out
on
valuable
features
by
creating
managing
our
issues
for
dub,
dub,
dub
or
slippers
outside
of
that
project,
and
I
lose
time
because
I
have
to
apply
all
those
labels
to
my
merge
requests
when
if
it
was
just
created
in
the
same
project,
the
labels
are
automatically
applied
and
the
branch
name
is,
and
everything
has
a
standard
then
the
third
is
my
sprint.
C
Yeah
mine
was
just
about
I've,
seen
an
I've
gotten,
a
few
issues
where
there's
just
a
lot
of
the
boilerplate
is
left
in
from
the
issue
templates,
which,
like
I
love
a
good
issue
template
and
I
tried
to
use
them.
I
think
they're
super
helpful,
but
I
think
something
just
like
an
education
piece
for
people
using
them
is,
like
you
know,
fill
out
the
prompts,
but
like
delete
all
the
stuff
that
you
don't
fill
out
like.
C
I
think
that,
like
giving
people
the
permission
like
you
can
just
delete
it
like
it's
cool
like
if
it's
irrelevant,
because
it's
super
hard
to
parse
out
the
useful
information
and
like
what
is
relevant
information
versus
what
is
just
stuff
left
over
from
the
templates.
I
think
someone
suggested
simpler
templates
somewhere
and
I
think
that's
I
think,
that's
useful
too.
I
do
I
like.
I
like
the
I
like
writing
and
I
like
the
documentation.
I
like
the
the
long-winded
template
stuff.
I
just
want
clearer
information
versus
boilerplate.
D
This
leads
into
the
16.
The
agency
day
templates
sometimes
have
missing
resources.
For
example,
they
have
a
link
to
the
figma
files
that
I'll
be
building
this
page
out,
because
that
figma
file
and
I'll
click
on
it
and
there's
nothing
there.
So
I
then,
therefore
think
the
design
is
not
ready
when,
in
fact
it
is
it's
just
completed
in
a
separate
issue.
A
A
You
know
what
doesn't
work.
I'm
seeing
a
lot
of
themes,
we'll
synthesize
this
as
we
go
forward,
but
I
thought
it
would
also
be
good.
You
know:
we've
got
a
little
bit
more
time
here,
so
we
can
cruise
through
this
there's
only
eight
items
with
some
sub
items
about
like
hearing
from
the
team
and
the
people
that
are
using
this,
like
what
would
make
it
better
for
you
and
I
added
a
little
caveat
and
I
forgot
a
there.
A
We
go
like
with
as
little
change
as
possible,
so
not
not
trying
to
like
reinvent
the
wheel
here.
But
what
can
we
do
so
laura?
I
see
you're
first.
F
Yeah,
I
know
that
there's
been
a
bit
of
talk
about
sharing
a
board
during
sprint
planning
when
we
have
spring
planning
meetings
anyway,
and
we
do
a
google
doc
like
this.
It
would
just
be
great
to
have
a
board
that
has
maybe
just
our
team,
because
there
is
a
board
that
I
linked
there.
That
is
like
it
looks
like
all
of
marketing
there's
so
many
people,
it's
really
chaotic
to
just
know
what
what
we're
doing
and
what's
kind
of
relevant
for
for
us.
F
Maybe
that's
a
label
or
something
just
to
be
able
to
see
like
really
quick.
Oh,
like
you
know,
tyler's
got
all
this
stuff
in
progress.
One
of
it
is
related
to
a
thing.
I'm
doing
can
tyler
help
me
with
that
thing,
or
is
he
too
busy
like
just
kind
of
seeing
what
other
people
are
up
to
before
I
go
like
bothering
them
and
pinging
them
and
and
that
kind
of
helps?
F
If
someone
externally
asks
for
work
that
needs
to
be
done
like
today,
we
have
a
link
to
see
like
how
busy
people
are
or
how
available
people
are
to
do
that.
That
kind
of
work.
So
maybe
that's
just
a
label
but
yeah.
C
Yeah
similar
to
kind
of
same
idea
just
think
about
as
little
change
as
possible.
I
think
that
our
sprint
integration
has
made
huge
strides
in
terms
of
like
the
sprint
workflow
overall,
and
this
has
been
like
like
night
and
day.
C
This
last
print
cycle
has
been
awesome
and
I
think
that
something
was
working
well
like
the
google
doc
agenda
is
great,
and
I
wonder
if
we
can
do
some
of
the
stuff
we
do
in
that
agenda
in
a
board,
whichever
board,
whatever
the
right
board,
is,
perhaps
it's
laura's
suggestion
of
the
board,
but
we
wouldn't
add
any
other.
C
It
would
be
the
same
thing
we
have
been
doing
in
the
agenda
and
I
know
like
thinking
about
like
I'm
gonna
be
out
on
monday,
and
I
was
going
to
write
a
note
in
the
sprint
agenda
of
like
hey,
assign
me
whatever.
I
don't
even
know
what
that
might
be,
because
there's
like
not
a
place
that
I
can
go
to
say
like
what
is
the
backlog
right.
C
If
I'm
thinking
about
like
kanban
scrum
like
I,
I
don't
know
what
someone
might
give
me
for
next
sprint,
I'm
happy
to
field
whatever
and
take
whatever
I
have
the
whole
sprint
open.
I
don't
have
any
like
big
thing,
I'm
worried
about,
but
like
yeah,
if
we
had
like
digital
experience
board-
and
I
could
say
like
oh
hey-
I
see
these
issues
like
these
would
be
good
ones.
For
me,
I'm
happy
to
take
whatever
that
would
be
super
useful.
B
I'm
up
next,
something
that
I
wanted
to
get
into
into
the
better
habit
of
is,
I
think,
a
lot
of
the
like
limitations
of
boards
and
similar
type
things
could
be
communicated
upward
more
consistently.
B
I
did
an
example
for
like
a
little
thing
where
it's
like
when
you're
doing
formatting
within
markdown
within
an
issue
hitting
ctrl
z,
doesn't
undo
the
formatting
when
you
click
on
the
ui
for
it,
and
so
then
I
made
an
issue
for
that,
and
so
then-
and
it's
getting
picked
up
at
some
point
and
like
you-
can
see
that,
like
all
the
tags
and
people
who
have
seen
it,
which
is
awesome,
I
think
doing
that
more
often
makes
it
so
that
we
can
actually
make
the
product
better
than
just
like
complaining
about
it
and
never
doing
anything
about
it.
B
On
a
different
note,
I
suggest
that
we
look
at
issue
templates,
that
we
have
existing
and
try
to
find
ones
that
work
better
for
us
in
particular,
in
in
my
like
internal
stuff.
A
lot
of
it
is
just
simply
like.
Why
am
I
doing
something?
How
am
I
doing
it?
What
am
I
doing?
And
it's
just
like
simple
straight
to
the
point,
and
it's
not
something
that
feels
like
is
getting
in
the
way
of
me
doing
work.
B
A
B
That
would
also
help
us-
and
I
also
just
wanted
to
talk
about
the
effectiveness
of
the
changes
on
a
string
investment
basis.
I
think
we
also
talked
about
that
like
when,
in
the
middle
of
us
friend,
something
we'll
get
changed
so
just
helping
that
all
of
that
gets
like
sorted
out
and
making
sure
that
things
get
locked
in
as
we
work
on
stuff,
oh
wow,
I
realized
I
had
a
lot
more
in
here,
get
into
the
habit
of
adding
updating
pages
to
the
handbook.
B
I
think
tyler
brought
up
this
excellent
point
about
making
sure
that
things
get
written
in
like
inside
of
an
issue
format
having
an
mr
format
where
the
deliverable
at
the
end
of
that
is
a
contribution
to
the
handbook.
I
think
that's
really
really
interesting.
I
think
that
there's
an
opportunity
there
for
us
to
improve
our
own
documentation.
B
B
I
see
that
just
wrote
something
and
I'm
just
reading
it
really
quickly.
Yeah
anyway,
I'm
just
gonna
keep
going
just
because
yeah
number
seven.
I
think
we
can
also,
just
in
general,
be
more
assertive
with
our
agency
style
issues.
I
think
a
lot
of
us
like
to
think
of
us
as
like
fun
like.
What's
that
analogy,
we
use
like
when
we're
button,
pressing
like
people,
robots
and,
and
I
want
to
make
sure
that
we're
being
like
using
our
expertise
more
critically
than
just
like
this
is
the
issue
that
was
given.
B
So
let
me
deliver
on
it.
Let
me
ask
questions
and
make
them
like
think
about
their
own
assumptions
in
the
claim
that
they're
making
and
try
to
see
if
there's
a
better
solution
or
an
easier
solution,
or
ideally,
both
I've
wrote
some
sub
points
about
whether
we're
like
asked
to
question.
B
If
a
us
agency
task
is
even
like
a
right
idea
being
transparent
about
timelines
and
how
long
things
take
as
an
mvc,
it
could
be
as
simple
as
when
you
get
an
agency
test,
just
check
in
with
the
person
who's
the
stakeholder
for
that
right
away.
Instead
of
waiting
on
it,
that's
something
that
I
just
did
today
for
the
first
time,
and
I
thought
that
could
be
helpful.
B
I
also
just
wrote,
like
scrum
master
question
mark
I
don't
know
if
that
discussion
has
ever
gone
across.
I
don't
know
if
that
should
be
an
explicit
responsibility
within
our
team
during
sprint
planning
that
we
can,
just
during
that
time,
devote
20
minutes
to
all
of
us.
Like
interim.
Do
that
ourselves,
it
seems
very
unlikely
that
we'll
get
that
person
dedicated
person.
A
Awesome
thanks.
Everyone
we're
we're
one
minute
to
time
here
so
becky
if
you've
made
it
to
the
end
of
this
discussion,
the
doc
I
will
link
you
to
has
the
discussion
points
that
we
documented
before
we
hit
record
so
yeah.
I
look
forward
to
you
know
making
this
making
this
even
more
effective
I'll,
stop,
sharing
and
stop
recording.