2. Over
a
year
ago,
I
started
on
an
new
and
interesting
journey.
I
was
assigned
to
work
on
an
Agile
team.
I
came
from
a
traditional
waterfall
background.
I
had
a
clear
understanding
what
my
role
was
on
the
team.
What
my
deliverables
were,
how
long
it
would
take
to
create
them.
My
world
was
very
straightforward
then.
My
exposure
to
agile
prior
to
my
current
role
was
academic.
There
was
this
thing
called
sprints,
where
developers
did
short
bursts
of
work,
and
then
they
would
iterate.
And
UX
work
all
occurred
in
this
thing
called
Sprint
Zero.
Before
the
dev
teams
start
working.
This
presentation
is
my
experience
about
being
embedded
in
an
Agile
team
and
being
immersed
in
the
process.
As
you
can
imagine,
this
was
quite
the
change
for
me.
Interestingly
enough,
both
change
management
and
agile
talk
about
the
Five
Stages
of
Change
adoption.
This
is
based
on
the
Five
Stages
of
Grief.
I
will
use
this
model
to
share
my
experience.
3. DENIAL
Denial
For
me,
denial
often
presents
itself
as
optimism.
Hey,
Agile
is
new
for
me,
but
I
would
really
like
to
learn
about
it.
I’ll
still
be
able
to
do
my
usual
process
in
the
mystical
Sprint
Zero.
Not
the
case.
4. DENIAL
Denial
For
me,
denial
often
presents
itself
as
optimism.
Hey,
Agile
is
new
for
me,
but
I
would
really
like
to
learn
about
it.
I’ll
still
be
able
to
do
my
usual
process
in
the
mystical
Sprint
Zero.
Not
the
case.
5. OP TIMIS TIC
Denial
For
me,
denial
often
presents
itself
as
optimism.
Hey,
Agile
is
new
for
me,
but
I
would
really
like
to
learn
about
it.
I’ll
still
be
able
to
do
my
usual
process
in
the
mystical
Sprint
Zero.
Not
the
case.
6. I
am
part
of
a
Product
Team.
The
product
team
is
made
up
a
lead
from
each
functional
group.
There
is
a
dev
lead,
a
UI
lead,
a
QA
lead,
myself
as
the
UX
lead
and
the
product
manager
along
with
the
Scrum
Manager.
We
created
the
Initial
backlog
together.
This
enormous
sprawl
of
sticky
notes
is
a
our
project?
This
is
the
documentation?
This
is
the
map
we’re
going
to
follow?
No
requirements,
no
speciRications?
7. JSTOR HOME SEARCH BROWSE MyJSTOR
<Coverage>, <Volumes>
Published by: <Lorem Ipsum Press>
Books in Series
<Series Title>
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam sagittis, libero non vestibulum auctor, nibh orci malesuada
diam, quis dignissim leo augue eu risus. Duis bibendum, dui sit amet suscipit pellentesque, felis tortor auctor augue, ut
dapibus ipsum urna in velit. Sed ultricies varius nibh at aliquet. Mauris vehicula mi dapibus mauris tempus posuere. Vivamus
dapibus condimentum nulla a vestibulum. Nam lorem arcu, vulputate sed varius vel.
Month Year
<Title>
<Author>
Stable URL: http://www.jstor.org/stable/xxxxxx
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam sagittis, libero non
vestibulum auctor, nibh orci.
Month Year
<Title>,
<Author>
Stable URL: http://www.jstor.org/stable/xxxxxx
Month Year
<Title>
<Author>
Stable URL: http://www.jstor.org/stable/xxxxxx
<Subtitle>
<Subtitle>
<Subtitle>
, <Author>, <Author>
1
4
3
7
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam sagittis, libero non
vestibulum auctor, nibh orci.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Etiam sagittis, libero non
vestibulum auctor, nibh orci.
Notes: List of Series/Sets (LOSS)
BLUE = BKS-89
1. Series Title is NOT clickable.
2. Coverage: span of years. Format will
be YYYY-YYYY.
Computed based on the first published
year of a volume in a series and the last
published volume in a series.
Volumes: total number of volumes in the
series: X Volumes
Publisher: name is clickable and goes to
the Publisher page.
3. Books in Series:
The volumes are shown in the order of
the published date, with the most recent
first.
Each book may contain the following
information:
Title: On click, goes to the book TOC.
Subtitle: OPTIONAL. If a subtitle does
not exist, do not show an empty row.
Authors: Not clickable from this page
OPTIONAL: If more then one Author,
they are separated by comma.
STABLE URL: Not clickable
Brief snippet: First 50 words of book
blurb.
ORANGE = Separate Cards
4. Series Summary: X characters long.
If no summary, page content moves up.
This MAY be future content.
5. Access Key:BKS 91
Should work as it currently does.
6. Access Icons: BKS-92
Should work as it currently does.
7. Global Search: BKS-93
Should work as it currently does.
2
6
5
, <Author>, <Author>
, <Author>, <Author>
J
B
J
J
J
J
1
Notes:
This is first pass and the icons attached are not the final icons.
Success Criteria:
An icon appears in the top right corner of each search result that indicates that it is a Book,
Journal, or Pamphlet.
These graphics should meet accessibility standards.
And
I
was
creating
what
I
will
call
JIT
wireframes.
Instead
of
trying
to
understand
the
entirety
of
the
functionality
of
the
work
upfront,
I
was
creating
very
discrete
artifacts
to
illustrate
stories.
Learning
to
create
in
terms
of
“passes”
and
“not
perfect”
Pulls
dev
into
the
process
earlier
8. ANGER
Anger
(I’ll
call
this
frustration)
The
Product
Team
experiences
a
lot
of
churn.
As
we
plan
sprints,
we
are
pulling
stories
out
of
the
backlog
that
we
had
an
understanding
of
“way
back
when”
but
may
have
lost
the
full
meaning
of
it
in
the
now.
This
feels
inefRicient
to
me.
If
we
had
written
things
down
more
completely
“way
back
when”
then
maybe
we
wouldn’t
have
to
spend
hours
trying
to
Rigure
out
what
that
sticky
mean.
Tension
with
the
dev
team.
It
turns
out
they
want
pixel
perfect
wireframes.
9. ANGER
Anger
(I’ll
call
this
frustration)
The
Product
Team
experiences
a
lot
of
churn.
As
we
plan
sprints,
we
are
pulling
stories
out
of
the
backlog
that
we
had
an
understanding
of
“way
back
when”
but
may
have
lost
the
full
meaning
of
it
in
the
now.
This
feels
inefRicient
to
me.
If
we
had
written
things
down
more
completely
“way
back
when”
then
maybe
we
wouldn’t
have
to
spend
hours
trying
to
Rigure
out
what
that
sticky
mean.
Tension
with
the
dev
team.
It
turns
out
they
want
pixel
perfect
wireframes.
10. F R U S T R AT I O N
Anger
(I’ll
call
this
frustration)
The
Product
Team
experiences
a
lot
of
churn.
As
we
plan
sprints,
we
are
pulling
stories
out
of
the
backlog
that
we
had
an
understanding
of
“way
back
when”
but
may
have
lost
the
full
meaning
of
it
in
the
now.
This
feels
inefRicient
to
me.
If
we
had
written
things
down
more
completely
“way
back
when”
then
maybe
we
wouldn’t
have
to
spend
hours
trying
to
Rigure
out
what
that
sticky
mean.
Tension
with
the
dev
team.
It
turns
out
they
want
pixel
perfect
wireframes.
11.
12. BARGAINING
Bargaining
(Resigned)
With
each
sprint
review,
I’m
beginning
to
better
understand
what
the
developers
need
from
me.
And
we
It
becomes
a
negotiation.
During
sprint
planning,
making
sure
my
deliverables
are
clearly
marked
up
and
expectations
are
set.
And
Rinding
a
common
language.
The
new
language
involves
stating
explicitly
this
is
a
“Rirst
pass”,
it
is
not
a
“perfect
representation
of
the
Rinal
product
13. BARGAINING
Bargaining
(Resigned)
With
each
sprint
review,
I’m
beginning
to
better
understand
what
the
developers
need
from
me.
And
we
It
becomes
a
negotiation.
During
sprint
planning,
making
sure
my
deliverables
are
clearly
marked
up
and
expectations
are
set.
And
Rinding
a
common
language.
The
new
language
involves
stating
explicitly
this
is
a
“Rirst
pass”,
it
is
not
a
“perfect
representation
of
the
Rinal
product
14. R E S I G N E D
Bargaining
(Resigned)
With
each
sprint
review,
I’m
beginning
to
better
understand
what
the
developers
need
from
me.
And
we
It
becomes
a
negotiation.
During
sprint
planning,
making
sure
my
deliverables
are
clearly
marked
up
and
expectations
are
set.
And
Rinding
a
common
language.
The
new
language
involves
stating
explicitly
this
is
a
“Rirst
pass”,
it
is
not
a
“perfect
representation
of
the
Rinal
product
15. While
the
product
team
sizes
the
story,
the
dev
team
writes
the
tasks
it
will
take
to
meet
the
speciRied
success
criteria.
If
the
story
involves
a
UX
component,
I
make
sure
the
team
understands
the
intended
functionality
and
as
many
of
the
rules
for
that
story.
And
sometimes,
they
know
more
than
I
do.
We
enter
a
collaboration.
Understanding
the
scope
of
the
“story”
16.
17. And
I
am
with
the
team
throughout
the
entire
process.
I
don’t
work
on
deliverables
for
a
few
weeks
and
disappear.
I
only
recently
return
to
my
cube
to
work
on
my
deliverables.
I
work
in
the
colab
WITH
the
developers
and
the
Product
Team
in
an
open
collaboration
space.
Insert
photo
of
colab
space.
Dev
team
and
product
team
18. DEPRE SSION
Things
are
going
well,
but
I
can’t
get
comfortable.
I
look
at
the
backlog
which
we
have
now
mapped
out
against
all
of
our
sprints.
19. DEPRE SSION
Things
are
going
well,
but
I
can’t
get
comfortable.
I
look
at
the
backlog
which
we
have
now
mapped
out
against
all
of
our
sprints.
20. WORRY
Things
are
going
well,
but
I
can’t
get
comfortable.
I
look
at
the
backlog
which
we
have
now
mapped
out
against
all
of
our
sprints.
21. I’m
anxious.
I
can’t
trust
in
this
process.
Looking
at
the
amount
of
work
we
have
to
do
with
NO
requirement
or
specs
is
making
me
nervous.
But
my
team
keeps
reassuring
me
that
we
don’t
need
that
documentation.
Insert
backlog
breakdown
slide
22. ACCEPTANCE
Acceptance
As
this
project
progressed
our
business
model
changed.
This
forced
a
change
in
the
requirements,
the
technology,
and
the
workRlow.
Assumptions
we
started
off
with
were
no
longer
correct.
With
each
change
I
began
to
realize
that
it
was
a
good
thing
that
I
hadn’t
spent
hours,
maybe
weeks,
deRining
something
that
no
longer
existed.
Rather
than
wasting
that
effort,
the
entire
team
was
able
to
adjust
and
course
correct
with
little
sunk
cost.
I
began
to
accept
that
this
process
was
working.
24. While
the
product
team
sizes
the
story,
the
dev
team
writes
the
tasks
it
will
take
to
meet
the
speciRied
success
criteria.
If
the
story
involves
a
UX
component,
I
make
sure
the
team
understands
the
intended
functionality
and
as
many
of
the
rules
for
that
story.
And
sometimes,
they
know
more
than
I
do.
We
enter
a
collaboration.
Understanding
the
scope
of
the
“story”
25. A
lot
of
work
isn’t
created
to
only
get
thrown
away
Pick
my
battles
26. Even
it
it’s
not
perfect
the
dev
team
still
looks
to
UX
for
direction
on
rules
and
edge
cases
UX
is
an
INTEGRAL
part
of
the
process
Liked
image
