Adapting Scrum for UX Teams

Adapting Scrum for
UX Design Teams
Tony Smith
Product Design Manager 
Hallmark Labs

I’m the Product Design Manager at Hallmark Labs. I lead design efforts across three
distinct products; a streaming video service, a digital greetings product, and a print-on-
demand greeting card product. Each has distinct features, objectives and product teams
that we support and inﬂuence.
I get to participate in strategy conversations now, but it wasn’t always that way.
“My name is Tony Smith and I am
a recovering strategy outsider.”

For years I worked to grow my skills, learn the latest tools and processes, and this got
me pretty far. But I began to see a pattern. I was routinely asked to deliver big results,
but wasn’t able to participate in the big decisions.
I’ve been told countless times by Product Managers, “We already know the features we
want, just make it look nice.”
It may be the most soul-crushing thing a UX Designer can hear. Instead of strategy, I
was working on this…

94,4?5)%@4)%@&'(P)%@4,4?5)'0%@&'()&'@4,4'%:J)
H,0'()H&%@)%@&5),4Q-45%A)>)G-5%)'44").0,4)
&'/0,.#%&0')%0)"0).J)G0=A))
90H)"0)>)K8#;4)&%)$0$L)H@4')%@4,4)&5)'0)
#(,44.4'%)0')H@#%)K70$L).4#'5A)>)'44")%0)
-'"4,5%#'")%@4)KH@JL)=4@&'")&%)#'")@0H)&%)
5-$$0,%5)0=G4+%&C45A
R#')J0-).#;4)&%)$0$S

+#)*"#$,-%-)./)012
3/.(4,-%-)./)012
>%)"&"'?%).#%%4,)H@4%@4,)>)H#5)#)+0'5-:%#'%D)H0,;&'()
/0,)#)5%#,%-$D)0,)4C4')#5)#).#'(4,A)>'I-4'+&'()$,0"-+%)
5%,#%4(J)@#5)#:H#J5)=44')#)+@#::4'(4A

Well, I was increasingly frustrated that other people were making critical decisions
affecting my work but without my input. I needed to ﬁnd out why this kept happening.
Why wasn’t I included?
There had to be good reasons. So I did some investigating…
So, now what?

First, I started with a familiar design-thinking structure. Essentially understand the
problem, generate ideas, test and measure. So that’s what I did. I interviewed
stakeholders like Product Managers and Tech Leads and uncovered some pain points.
• There was a lack of transparency into the design process.
• How long will it take?
• What will we get when you are done?
• How will that add value to the business?
Understand, Ideate, Validate

I also learned to speak the same language as stakeholders by paying attention to the
terminology they used and what inﬂuenced their decisions. Essentially, I created personas
for internal partners that helped me better understand their needs and behaviors.
• Some PMs just wanted to hit deadlines.
• Others had speciﬁc metrics they wanted to improve.
• Developers wanted clear design specs that were thorough and feasible.
• They also wanted to be included before they started building stuff.
Understand, Ideate, Validate

Trust
A common thread through all this was a lack of trust. I found it to be the biggest reason
design was left out of the equation.
• Leadership didn’t trust me to consider the best interests of the business.
• Product managers didn’t trust me to prioritize my work to hit deadlines.
• Developers didn’t trust me to design something feasible.

On top of that, conventional wisdom says you can have “too many cooks in the kitchen.”
They felt that as you include more people, it’s diﬃcult to make a decision. And often the
quality of the decision suffers.
There are so many excuses for excluding designers from important discussions. Once I
understood this, it was clear why no one asked my opinion.
Everyone thought my main goal was
to design cool stuff for my portfolio.

Now I had something I could focus on…
How can I build trust with these
people and prove my value?

“As a product team we need a process that can reliably produce
high quality deliverables within a predictable timeframe while
allowing flexibility when new information is introduced.”
You can look at this as a user story or a problem statement, but it captured my objectives and the needs of
those I worked with. It directly addressed concerns about quality, predictability and flexibility. All were
components I believed would build trust and create value for the business and users.
• Customer and business value are driven by quality.
• Internal teams and leadership need predictable timelines in order to plan and organize.
• Agile workflows require flexibility to respond to changing information and opportunities.
After gathering everyone’s input, I distilled it into a concise statement that captured my objectives.

Now I had an objective and a better understanding of the problems. So, I started doing
little tests with my own process. I tinkered with the way I tracked tasks and estimated
work. And I didn’t have to involve anyone else or disrupt their workﬂows. No one really
knew I was doing this at ﬁrst.
Eventually as a manager, I was able to test on a team to see how things scaled.
Test, Measure and Iterate

6@4).05%)&.$0,%#'%)$#,%)H#5)G-5%)(4%%&'()5%#,%4"A)[0)0'4)
,4#::J);'4H)#=0-%D)0,)+#,4")#=0-%D)0-,)$,0+455A)6@4J)0':J)
;'4H)&/)%@4J)H4,4)(4%%&'()C#:-4)/,0.)&%A))
>)"&"'?%)#5;)/0,)$4,.&55&0')=-%)>)"&")#5;)/0,)@4:$A)>%)H#5)
&.$0,%#'%)%0)&'+:-"4)#)=,0#"),#'(4)0/)$4,5$4+%&C45)%0).#;4)
5-,4)>)H#5'?%)0':J).#;&'()%@&'(5)4#5&4,)/0,).J54:/D)=-%)%@#%)>)
H#5)#""&'()C#:-4)%0)4C4,J)%4#.)>)H0,;4")H&%@A)!5)H4)/0-'")
5-++455)&%)H#5).-+@)4#5&4,)%0)(#&')5-$$0,%)#'")%@4')
&'%4(,#%4)H&%@)0%@4,)%4#.5A))
>)@#C4)J4%)%0)544)+0.$#'&45).#;4)5&('&T+#'%)+@#'(45)G-5%)
=4+#-54)&%?5)#)(00")&"4#)&')%@40,JA)W,D)=4+#-54)&%?5)#)=45%)
$,#+%&+4)#'")K]00(:4)"045)&%)%00AL)>%?5).4#5-,#=:4)5-++455)
%@#%?5)+,&%&+#:)%0)+@#'(&'().&'"5)#'")=-&:"&'()%,-5%A
]4%)*%#,%4"

>%)H#5)#:50)C4,J)&.$0,%#'%)%0)50+&#:&X4)%@4)
+0'+4$%D)H@&+@).4#'%)+0'5%#'%:J)%#:;&'()
#=0-%)H@#%)>)H#5):4#,'&'()#:0'()%@4)H#JA)>)@#")
+0-'%:455)@#::H#J)+0'C4,5#%&0'5)5@#,&'()&"4#5)
#'")(4%%&'()/44"=#+;A))
0-?")=4)5-,$,&54")@0H)&.$0,%#'%)%@054)
+0'C4,5#%&0'5)=4+0.4)#5)J0-)%,J)%0)5+#:4)J0-,)
$,0+455)%@,0-(@0-%)%@4)=-5&'455A)6@454)#,4)
%@4)$40$:4)H@0)H&::)@#C4)%0)#"#$%)%0)%@4)
+@#'(45)J0-)H#'%)%0).#;4A)]4%)%@4.)-54")%0)
%@4)&"4#)4#,:J)#'")(#&')%@4&,)5-$$0,%A
6#:;)#=0-%)&%)4'":455:J

After a lot of trial and error, I found some success. I have what I would call a “seat at the
table.”
These days I run ideation sessions to figure out where the product is going, I prioritize
roadmaps alongside product managers, and stakeholders come to me with questions
instead of solutions. This gives me real influence on product strategy and positions me
and our team as strategic partners, not service providers.
I finally made it!

*+,-. 12
0-).&(@%)'0%);'0H)%@&5)J4%)=-%)*+,-.)#'")
12)+#')#+%-#::J)=4)/,&4'"5^)
>)"&"'?%)#:H#J5)%@&';)%@&5)H#5)$055&=:4A)>)H#5)
:&;4)#):0%)0/)"45&('4,5)H@0)/4:%)J0-)G-5%)+0-:"'?%)
$-%)#)%&.4,)0')+,4#%&C&%JA)7-%%&'()#)"45&(')
%&+;4%)&')_>`!)/4:%)H,0'()#'")%00),45%,&+%&C4A))
N-%)&%?5)'0%)0':J)$055&=:4D)&%)+#')=4)%@4);4J)%0)
=-&:"&'()%,-5%)&')J0-,)0,(#'&X#%&0'A)>?::)5@0H)
J0-)@0H)>)"&")&%)#'")(&C4)J0-)$,#+%&+#:)&"4#5)
J0-)+#')&.$:4.4'%)%0)=,&'()J0-).0,4)
&'I-4'+4)&')$,0"-+%)5%,#%4(JA
<4%?5)=4)/,&4'"5

But first…
let me explain what I mean by Scrum.
Agile is way of working where you deliver small chunks of complete work. You can then
quickly learn if you’re on the right track and change course. It’s a response to waterfall where
you might complete an entire project over the course of many months before finding out you
missed the mark. That’s the gist of it.
Within Agile there are a two popular frameworks, Kanban and Scrum. They represent two
ends on a continuum of flexibility.

Agile
kanban scrum
I am here
Variable cycle times
Work focused on individual items
Flexible roles
Fixed sprints
Work completed in batches
Formal roles and events
more ﬂexible less ﬂexible
I’ve looked at both but gravitated towards Scrum because that’s what the developers around me used. My
hypothesis was if I adapted to an existing process, it would be easier to make progress. Everyone would be
using the same tools and speaking the same language.
It was only through trial and error that I found out which parts of Scrum had the most value for UX work.

Track
Tickets
Story Points
Sprints
Evaluate
Velocity
Accuracy
Optimize
Planning and Prioritization
Retrospectives
The key components I focus on are tracking, evaluating and optimizing, which start to resemble a common
design thinking structure.
• We need to gather data by tracking our work with story points and tickets.
• Then we evaluate that data looking for insights and opportunities.
• And we use those insights to make improvements the next time.
 
The right amount of Agile produces tangible artifacts that make the value of UX work more concrete.

Track
Tickets
Story Points
Sprints
Evaluate
Velocity
Accuracy
Optimize
Retrospectives
A common mistake I see with UX teams is trying to inﬂuence strategy based on theory. Everyone should
understand the value of user research. They should support information architecture best practices. But most
stakeholders I’ve encountered have little faith in theory until they see results applied to their speciﬁc product.
It’s too easy to dismiss UX principles by saying, “Well, it may have worked for that company, but we’re
different: our users are different, our business model is different.”
So let’s dig into how we can track design work using Scrum and start creating the stuff that makes UX work
more concrete.

Track
Tickets
Scrum uses tickets, story points and sprints to track work. Tickets are the basic building block that
describes the work you’re doing. They’re also a tool for building trust with other teams.
• You have to collaborate with others to deﬁne them.
• You need access to data to accurately estimate them.
• They provide visibility into the value you will deliver. 
Your tickets should describe objectives, deliverables and be clear about how they add value. But, how
do you decide how much work goes into a ticket?
• Is it a whole project?
• Is it just a small task?
• What’s the scope?

6,#+;
6&+;4%5
>)#$$,0#+@)&%)=J)%@&';&'()&')%4,.5)0/)
+0..0')12).&:45%0'45A)M0,)&'5%#'+4D)
!"#"$%&'D)("#)*+)#'"),-"&A)F#+@)@#5)
%J$&+#:)"4:&C4,#=:45)H@4%@4,)%@4J)#,4)
,4$0,%5D)H&,4E/,#.45)0,)50.4%@&'()4:54A)>)
"4%4,.&'4)H@#%)%@4)#$$,0$,&#%4)"4:&C4,#=:45)
#,4D)#'"),0-(@:J)@0H)"&Y+-:%)&%)H&::)=4)%0)
+0.$:4%4)%@4.A))
!:50D)"4T'&'()%&+;4%5)&5)#)(,4#%)0$$0,%-'&%J)
%0)4'(#(4)"4+&5&0'E.#;4,5)&')#)"&5+-55&0')
#=0-%)J0-,)$,0+455)#'")H@J)%@4)H0,;)&')%@&5)
%&+;4%)#""5)C#:-4A
[DESIGN] Enhanced registration experience
Story Points 5
Priority High
Status Backlog
Description
How might we improve the registration experience?
Consider reduced steps, progressive disclosure, and value
propositions for completion.
Deliverables are competitive analysis, concepts and tech review.

6,#+;
6&+;4%5
*0):4%?5):00;)#%)%@&5)4Z#.$:4P)
<4%?5)5#J)#)78)+0.45)%0)J0-)#'")5#J5D)
!"#$%#&'()&*+#&)(,-#'.&/)0&1#&/'#&.##2)3&
.23)245/)*&0'678699&/*&'#32.*'/*26):&"#&1/)*&
*6&(70/*#&2*&*6&.##&29&1#&5/)&3#*&,6'#&7#67;#&
2)*6&*+#&7'60(5*:<&
0-)+0-:")5&.$:J).#;4)#)%&+;4%)/0,)%@4)4'%&,4)
$,0G4+%)%@#%)&'+:-"45)"45&(')H0,;)#'")
5$4+5A)N-%)%@#%?5)"&Y+-:%)%0)45%&.#%4)
=4+#-54)%@4,4)#,4)50).#'J)C#,&#=:45A
Story Points 5
Priority High
Status Backlog
Description

6,#+;
[WIRE-FRAMES] Enhanced registration experi…
Story Points 5
Priority High
Status Backlog
Description
6&+;4%5
>'5%4#")>)H0-:")=,4#;)%@4)H0,;)&'%0)#%):4#5%)
c)%&+;4%5B)0'4)/0,)%@4)"45&(')H0,;)#'")0'4)
/0,)5$4+5A)
Story Points 5
Priority High
Status Backlog
Description
Story Points 5
Priority High
Status Backlog
Description

6,#+;
[SPECS] Enhanced registration experience
Story Points 5
Priority High
Status Backlog
Description
[WIRE-FRAMES] Enhanced registration experi…
Story Points 5
Priority High
Status Backlog
Description
6&+;4%5
0-)+0-:")4C4')(0)/-,%@4,)#'")@#C4)#)
54$#,#%4)%&+;4%)/0,)H&,4E/,#.45)&/)'44"4"A))
6@4)$0&'%)&5)%0):&.&%)%@4)5+0$4)0/)#)%&+;4%)
4'0-(@)%@#%)J0-)+#')#++-,#%4:J)45%&.#%4)&%A)
!'")%@4)H#J)%0)+0..-'&+#%4)J0-,)45%&.#%4)
&5)H&%@)5%0,J)$0&'%5A
Story Points 5
Priority High
Status Backlog
Description
Story Points 5
Priority High
Status Backlog
Description

Track
Story Points
Story points can be a difficult concept to grasp if you haven’t used them before.
They basically provide a sense of how difficult one ticket is compared to another. For instance a 2 point ticket
is double the effort of a 1 point ticket. This gives you a useful way to compare one ticket to another without
committing to a specific delivery date. Story points are particularly well suited to design work since it’s hard
to estimate the exact amount of time it will take. But it will give stakeholders a rough idea of when they might
expect deliverables.
1 13
least complex most complex
2 3 5 8

Track
Story Points
1 13
2 3 5 8
They are comparable to t-shirt sizes where you might estimate in terms of small, medium, and large. You
don’t have to know an exact delivery date to know a small ticket should get done faster than a large ticket.
And you can use your past experience with small tickets to give you a better sense of how long they typically
take. But by avoiding due dates, you maintain ﬂexibility which was an important part of our original objective.

Track
Story Points
In my experience, teams base the range of points on the ﬁbonacci sequence where you add
the two previous numbers to get the next. This creates a non-linear progression where the
distinctions between estimates are meaningful.
It’s hard for me to know the difference between a 7, 8 or 9. They are just so close together.
They basically feel the same. But the difference between a 5 and 8 is more clear.
Usually story points max out at 13 which represents the most complex task you can
complete within 2 weeks. It’s an arbitrary value that sets the maximum. Everything else is
compared against this standard.
1 13
2 3 5 8

Track
Story Points
So let’s take a look at how we might score that ticket we just made…
We have our ticket to design some options for enhancing registration. I need to think about similar
tickets I’ve completed in the past, how much effort they took and how this one compares. In this
case I would score it a 5 for a few reasons
• The complexity is moderate because it’s an update to an existing design.
• I have a few past tickets in mind that were similar and they took several days to complete but
not a full week.
• Also, I want to include a little padding for stuff like meetings, feedback and revisions.
1 13
2 3 5 8

Track
Story Points
This gets me to a useful estimate that I can commit to and communicate to the product team.
By assigning 5 story points my team knows this will take more than 1 day but less than a week
because it’s a moderately complex task.
Don’t worry, your scoring will always be wrong the ﬁrst time you do it. You calibrate scoring over
time by reviewing past sprints and making adjustments. This process of calibration never ends.
But you have to start somewhere.
1 13
2 3 5 8

Track
Sprints
Sprints are where it all comes together.
You’ve created tickets that represent
manageable amounts of work based on
UX milestones. You estimated their
complexity relative to each other. But you
can’t work on everything at once.
To Do In Progress In Review Done
[SPEC] Add
password
reset to
settings
2
[WIRE-
FRAMES]
Enhanced
registration
experience
3
[RESEARCH]
Enhanced
registration
experience
5
[SPEC]
Subscription
button test
2
[SPEC]
Enhanced
registration
experience
2
[DESIGN]
Enhanced
registration
experience
8

Track
Sprints
Sprints contain the tickets that your team
expects to complete within 2 weeks. In this
case we have six tickets in various stages
of completion.
It’s these columns that provide
transparency into our progress over time.
Team members can see what you’re
working on, what’s been done, and where
you’re stuck waiting for more information.
To Do In Progress In Review Done
[SPEC] Add
password
reset to
settings
2
[WIRE-
FRAMES]
Enhanced
registration
experience
3
[RESEARCH]
Enhanced
registration
experience
5
[SPEC]
Subscription
button test
2
[SPEC]
Enhanced
registration
experience
2
[DESIGN]
Enhanced
registration
experience
8

Track
Sprints
The main goal I have for each sprint is to continually deliver value. That value can take the form of
reports, designs or specs. But we don’t want our partners to wait more than 2 weeks before they
see meaningful results from the UX team. Frequent and consistent delivery of value is a critical
component for building trust with your teams.
The best way to do this is to vary the types of tickets you include in a sprint. Small, production
oriented tickets ensure your dev teams have a steady stream of specs to work on. That way the UX
team isn’t seen as a blocker to progress.
At the same time you need to make progress on large, explorational tickets that contribute valuable
user insights to decision makers. This is critical to positioning the design team as strategic
partners. It also creates many more dev tickets down-stream providing even more cover for your
team in the future.

Track
Sprints
For example, let’s say you have a small ticket for adding an additional field on a registration screen.
It takes no time at all for an engineer to complete that work. Now they are looking for the next spec
to stay busy. You’ll never be able to outpace your dev team with only small tickets and make time
for strategic work.
Now let’s say you have a large project for designing a completely new feature. It may take more
time to explore concepts, research with users and finalize designs. But, when you’re finished you’ll
deliver many more tickets that keep devs busy for weeks or months. Now you have time for
strategic initiatives that expand your role in the organization.
The goal is to build sprints that balance both short and long term projects.

6,#+;
6&+;4%5)
*%0,J)70&'%5)
*$,&'%5
FC#:-#%4
V4:0+&%J)
!++-,#+J
W$%&.&X4
7:#''&'()#'")7,&0,&%&X#%&0')
`4%,05$4+%&C45
!%)%@&5)$0&'%D)H4?C4).#"4)0-,)%&+;4%5D)45%&.#%4")%@4&,)+0.$:4Z&%JD)#'")0,(#'&X4")%@4.)&'%0)
%H0EH44;)5$,&'%5A)WC4,)%&.4D)H4)5%#,%)%0)(4'4,#%4)C#:-#=:4)"#%#)#5)H4)+0.$:4%4)H0,;A)
[0H)&%?5)%&.4)%0)T'")0-%)H@#%?5)H0,;&'()#'")H@4,4)H4)'44")%0)&.$,0C4A
6,#+;
6&+;4%5)
*%0,J)70&'%5)
*$,&'%5
W$%&.&X4
7:#''&'()#'")7,&0,&%&X#%&0')
`4%,05$4+%&C45

Evaluate
Burndown Chart
A burndown chart is one tool for evaluating
a sprint as it progresses.
The grey line represents the ideal
progression from your total estimated
points (in this case 32) down to 0. If you
estimated accurately you should complete
all your tickets within two weeks. This
doesn’t always happen but it’s the goal.
The blue line represents actual work you
complete during the sprint. As you close
tickets the line drops. If you add tickets, it
rises. The shape of this line can tell us
some very important things.
Days
1 2 3 4 5 6 7 8 9 10
Points
0
32
guideline work remaining

Evaluate
Burndown Chart
Dipping below the guideline could mean
you are ahead of schedule. Even though
this tends to be positive, it’s a good idea to
capture why this happened.
• Did you improve your process allowing
you to complete tickets faster?
• Or, was your estimate wrong and you
missed an opportunity to schedule
more work?
Days
1 2 3 4 5 6 7 8 9 10
Points
0
32
Completing work
ahead of schedule

Evaluate
Burndown Chart
Up-ticks show that work was added
during the sprint. Again, it’s important
to find out why.
• Was there an unexpected request
forcing you to add tickets?
• Did you find out a ticket was harder
than you thought and had to add
points?
 
Sometimes late changes are
unavoidable. We just need to find out
why to prevent them in the future. And
now we have access to data to flag and
diagnose these events.
Days
1 2 3 4 5 6 7 8 9 10
Points
0
32
Points added
during sprint

Evaluate
Velocity Chart
A velocity chart is another way to
evaluate your process by comparing
completed sprints over time.
Here you can see your initial estimate
paired with the actual work you
completed. This can show you how
accurate your estimates are and how
consistent you are over time.
Sprints
1 2 3 4 5
Points
0
32
estimated actual

Evaluate
Velocity Chart
You may tend to over- or under-
estimate tickets.
Maybe you over-estimated because…
• You forgot to account for time-off
• maybe task objectives were unclear
so there was wasted time
 
Maybe you under-estimated because…
• you were being too conservative and
should have scheduled more work
• or maybe new process
improvements are paying off
Sprints
1 2 3 4 5
Points
0
32
estimated actual
Over-
estimated
Under-
estimated

Evaluate
Velocity Chart
You can also see how consistent your team
is over time.
As your sprints improve you begin to build
credibility by meeting commitments and
being transparent about your process.
Sprints
1 2 3 4 5
Points
0
32
estimated actual
Accurate estimation
+ consistency

Evaluate
Velocity Chart
You’re also required to strengthen relationships with the people you work with. You need their
perspectives and their data to estimate accurately. And, if stakeholders want 32 story points to be
completed in 2 weeks, they have to provide support. They don’t get the value they want unless you
get the collaboration you need.
Now that your process can be visualized and measured, it’s easier for teams to account for when
planning and prioritizing. More importantly, you build trust because people can count on you to
deliver value in a predictable way.

6,#+;
6&+;4%5)
*%0,J)70&'%5)
*$,&'%5
FC#:-#%4
V4:0+&%J)
!++-,#+J
W$%&.&X4
7:#''&'()#'")7,&0,&%&X#%&0')
`4%,05$4+%&C45
[0H)J0-?C4)(#%@4,4")"#%#)=J)%,#+;&'()J0-,)H0,;A)0-)+#')#:50)C&5-#:&X4)J0-,)0-%$-%)#'")5$0%)#,4#5)/0,)
&.$,0C4.4'%A)<4%?5):00;)#%)%H0);4J).44%&'(5)%@#%)@4:$)J0-)0$%&.&X4)J0-,)$,0+455)#'")(4%)%@4).05%)0-%)0/)
J0-,)5$,&'%5A
6,#+;
6&+;4%5)
*%0,J)70&'%5)
*$,&'%5
FC#:-#%4
V4:0+&%J)
!++-,#+J

47:.'* )&-5.'* =-.:-5.'* )!&,5.'* 9,".'*
C5.##(#4%H%
C/("/()(I.)("#
J6)/"0
-269)(E6
W$%&.&X4
7:#''&'()m)7,&0,&%&X#%&0'
7:#''&'().44%&'(5)@#$$4')=4/0,4)%@4)5$,&'%)
5%#,%5A)6@&5)&5)H@4,4)J0-,)%4#.)+0.45)
%0(4%@4,)%0)"&5+-55)%@4)"4%#&:5)0/)%&+;4%5):&;4)
,4Q-&,4.4'%5D)45%&.#%45)#'")$,&0,&%JA)>%?5)#:50)
#')0$$0,%-'&%J)/0,)"45&(')%0)=4).-+@).0,4)
&'C0:C4")&')5%,#%4(&+)+0'C4,5#%&0'5A))
N4+#-54)H4)#,4)/0+-54")0')5@0,%)%&.4E
/,#.45)0/)%H0)H44;5D)H4)+#'?%)"0)4C4,J%@&'(A)
O4)'44")+:4#,)0=G4+%&C45)#'")#)"4+&5&0')
#=0-%)H@#%)&5)%,-:J)&.$0,%#'%)%0)H0,;)0'A)12)
%4#.5)5@0-:")=4)$,4$#,4")%0)&'/0,.)%@#%)
"&5+-55&0')H&%@)-54,)&'5&(@%5)#'")$,0G4+%4")
=-5&'455)C#:-4A

47:.'* )&-5.'* =-.:-5.'* )!&,5.'* 9,".'*
C5.##(#4%H%
C/("/()(I.)("#
J6)/"0
-269)(E6
W$%&.&X4
7:#''&'()m)7,&0,&%&X#%&0'
>"4#::J)J0-)5@0-:")&'+:-"4)%@4),4:4C#'%)
$,0"-+%).#'#(4,5)#'")%4+@):4#"5)=-%)%@&5)
%J$&+#::J)"045'?%)@#$$4'A)a44$)&').&'")%@4J)
#,4)$#,%&+&$#%&'()&')%@4)5#.4).44%&'(5)0')
%@4)%4+@)5&"4A)*0)&%?5)-$)%0)%@4)"45&(')%4#.)%0)
H0,;)+:054:J)H&%@)%@4&,)$,0"-+%)%4#.5)0n&'4)
%0)#++-,#%4:J)&'/0,.)%@4&,)5$,&'%5A)
W'+4)4C4,J0'4)&5)+:4#,)0')%@4)H0,;)%@#%)
'44"5)%0)=4)"0'4)J0-)+#')-54)"#%#)/,0.)
J0-,)C4:0+&%J)+@#,%)%0)"4+&"4)@0H).#'J)
%&+;4%5)J0-)+#')+0.$:4%4)&')%H0)H44;5A)
!(#&'D)=4+#-54)J0-,)H0,;I0H)&5).4#5-,#=:4)
#'")$,4"&+%#=:4D)5%#;4@0:"4,5)@#C4)%0)
+0'5-:%)%@4)"45&(')%4#.)#=0-%)#C#&:#=:4)
,450-,+45)#'")%&.4:&'45A

W$%&.&X4
7:#''&'()m)7,&0,&%&X#%&0'
6@&5)&5)0'4)0/)%@4).05%)&.$0,%#'%)#5$4+%5)0/)
*+,-.)%@#%)>):4#,'4")/,0.)"4C)%4#.5A))
*$,&'%5)#,4)#')0=G4+%&C4)#55455.4'%)0/)
+#$#+&%J)#'")$,&0,&%&45A)!'")%@4,4)#,4),-:45)
(0C4,'&'()H@#%)(4%5)H0,;4")0')#'")H@#%)
"045'?%A)6&+;4%5)H&%@0-%)+:4#,)0=G4+%&C45)"0'?%)
(4%)&'+:-"4"A)!'")'4H),4Q-45%5)#,4'?%)#""4")
H&%@0-%),4.0C&'()50.4%@&'()T,5%A)
7,&0,&%&X#%&0')=4+0.45).0,4):&;4)#).#%@)
$,0=:4.)H@4,4)J0-)4&%@4,)@#C4)%@4)+#$#+&%J)
0,)J0-)"0'?%A
47:.'* )&-5.'* =-.:-5.'* )!&,5.'* 9,".'*
C5.##(#4%H%
C/("/()(I.)("#
J6)/"0
-269)(E6

47:.'* )&-5.'* =-.:-5.'* )!&,5.'* 9,".'*
C5.##(#4%H%
C/("/()(I.)("#
J6)/"0
-269)(E6
W$%&.&X4
`4%,05$4+%&C45
!),4%,05$4+%&C4)&5)#).44%&'()@4:")#%)%@4)4'")
0/)#)5$,&'%)+J+:4)%0),4C&4H)%@4)H0,;)%@#%)H#5)
+0.$:4%4"A)
>%?5)#:50)#)%&.4)/0,)4#+@)%4#.).4.=4,)%0)
5@#,4)H@#%)H4'%)H4::D)H@#%)+#')=4)&.$,0C4"D)
#'")H@#%)#+%&0'5)5@0-:")=4)%#;4')%0).#;4)
%@054)&.$,0C4.4'%5A)6@&5)0':J)H0,;5)H@4')
$40$:4)#,4)4.$0H4,4")%0)(&C4)@0'45%D)
+0'5%,-+%&C4)/44"=#+;A)O4)H#'%)%0)+4:4=,#%4)
%@4)H&'5)H&%@0-%)&('0,&'()0-,).&5%#;45A)
U 3&")H4).&55)%@4).#,;)H&%@)0-,)45%&.#%45S)
<4%?5),4E+#:&=,#%4)0-,)5+0,&'(A)
U O4,4)H4)H#&%&'()/0,)5%#;4@0:"4,)/44"=#+;)
%@#%)'4C4,)+#.4S)<4%?5)H0,;)0')=4%%4,)
+0..-'&+#%&0'A

47:.'* )&-5.'* =-.:-5.'* )!&,5.'* 9,".'*
C5.##(#4%H%
C/("/()(I.)("#
J6)/"0
-269)(E6
W$%&.&X4
`4%,05$4+%&C45
O@4')J0-?,4)"0'4D)J0-)5@0-:")@#C4)#)+:4#,)
$#%@)/0,)&.$,0C&'()J0-,)%4#.?5)$4,/0,.#'+4A)
`4%,05$4+%&C45)#:50)$,0C&"4)#'0%@4,)
0$$0,%-'&%J)%0)4Z$#'")%@4)&'I-4'+4)0/)J0-,)
%4#.A)
U 8#J=4):#+;)0/)&'/0,.#%&0')"4,#&:4")#)
$,0G4+%A)[0H)J0-)+#')5@0H)@0H)4#,:J)
#++455)%0)"#%#)+#')#//4+%)%@4)$4,/0,.#'+4)
0/)J0-,)%4#.A)
U 8#J=4)5@&/%&'()0=G4+%&C45).#"4)&%)"&Y+-:%)
%0)"4+&"4)H@4')#)%&+;4%)H#5)"0'4A)0-)+#')
=4)#)=4%%4,)#"C0+#%4)/0,)+:4#,)0=G4+%&C45)
H@4')J0-)@#C4)"#%#)5@0H&'()%@4)
+0'54Q-4'+45)0/)%@4)#:%4,'#%&C4A

Track
Tickets
Story Points
Sprints
Evaluate
Velocity
Accuracy
Optimize
Retrospectives
Now we’ve seen how Scrum helps us track, evaluate and optimize our work. But how does that help us get a
seat at the table? How are we any closer to inﬂuencing strategy?

outcomes + trust = inﬂuence
Earlier I said that a lack of trust was the biggest reason design was left out.
A foundational component of trust is your reputation. Or, the collection of past experiences
someone has with you. Do you consistently do what you say you’ll do? If so, people can predict
outcomes based on what you say.
Scrum generates measurable artifacts for building your reputation.

M&,5%)0/)#::)J0-)#,4)#=:4)%0).4#5-,4)0-%+0.45A)FC4,J0'4)+#')544)@0H).-+@)J0-)"4:&C4,D)@0H)
+0'5&5%4'%)J0-)#,4)0C4,)%&.4)#'")%@4)C#:-4)J0-)+,4#%4A)
!:50D)J0-)@#C4)#++455)%0)%00:5)/0,)&"4'%&/J&'()$,0=:4.5)&')J0-,)$,0+455D)"&#('05&'()%@4)+#-545)#'")
TZ&'()%@4.A)0-?,4)#=:4)%0)%#;4)Q-&+;)#+%&0')#'")%45%)'4H)50:-%&0'5A)!'"D)J0-)+#'),4+0('&X4)#'")
,4&'/0,+4)$05&%&C4)=4@#C&0,A)
!5)J0-,)$,0+455)&.$,0C45D)J0-,)0-%+0.45)H&::)&.$,0C4A)O0,;)H&::)=4)"0'4)H&%@):455)/,&+%&0'A)!'"D)
"45&(')50:-%&0'5)H&::)@#C4).0,4)&.$#+%A)>.$,0C&'()%@4)Q-#:&%J)0/)J0-,)H0,;)#:50).#;45)&%).-+@)
4#5&4,)/0,)0%@4,5)%0)%,-5%)J0-A
0-%+0.45)o)%,-5%)p)(#K16#96

*+,-.)$,0C&"45)#)/,#.4H0,;)/0,)&'+:-"&'()0%@4,5)&')J0-,)$,0+455)%0)#:&(')#'")H0,;)%0(4%@4,)%0)"4:&C4,)
C#:-4)4#+@)5$,&'%A))
0-)+#')$,0C&"4).0,4)%,#'5$#,4'+J)&'%0)@0H)J0-)H0,;)#'")#"")C#:-4)%0)%@4)=-5&'455)#'")J0-)+#')
4'+0-,#(4)"&5+-55&0'5)#=0-%)$,&0,&%J)#'")5%,#%4(J)%@#%)#:&(')"45&(')H&%@)%@4),45%)0/)%@4)$,0"-+%)%4#.A)
740$:4)+#')%,-5%)J0-)H@4')%@4J)-'"4,5%#'")@0H)J0-)H0,;)#'")544)%@#%)J0-)#:50)+#,4)#=0-%)H@#%)
.#;45)%@4.)5-++455/-:A
0-%+0.45 o)%,-5%)p)(#K16#96

>'I-4'+4)+#')%@4')@#$$4')#%)=0%@)#)%#+%&+#:)#'")5%,#%4(&+):4C4:A))
!%)#)%#+%&+#:):4C4:D)5%,-+%-,4")%&.4:&'45)#'")#++-,#%4)45%&.#%45)#,4)@#,")/0,)5%#;4@0:"4,5)%0)&('0,4A)
*+0,&'().#;45)12)H0,;)Q-#'%&T#=:4)#'")+#$#=:4)0/)=4&'()+0'5&"4,4")&'),0#".#$5A)[0H)J0-)+#')
.4#5-,4)J0-,)=#'"H&"%@)#'")'4(0%&#%4)H@&+@)$,0G4+%5)(4%)"0'4)#'")H@4'A)
!%)%@4)5%,#%4(&+):4C4:D)J0-,)&'C0:C4.4'%)&5),4Q-&,4")&')0,"4,)%0).44%)=-5&'455)(0#:5A)0-)#,4)=4%%4,)
4Q-&$$4")%0)&'/0,.)5%#;4@0:"4,5)#=0-%)%@4)%,#"4E0//5)#'")+0'54Q-4'+45)0/)0'4)5%,#%4(J)0C4,)
#'0%@4,A)0-)=4+0.4)+,&%&+#:)%0),4"-+&'(),&5;)#'")&'+,4#5&'()+0'T"4'+4)&')#)$,0G4+%?5)5-++455A)
0-%+0.45 o)%,-5%)p)(#K16#96

Making it work for you…
Fortunately, there isn’t just one way to do this. My goal for you is to be able to put these ideas into
practice with your team in your unique environment.

Start small
It’s important to start where you can. Often that means testing this on one project
or only yourself instead of a whole team.
The beneﬁt is there are no external dependencies. You won’t need to ask for
permission, convince stakeholders or change the way other teams work.
It also allows you to make mistakes and learn before scaling up.

Find opportunities to expand
When you find success at a small scale, you can start looking for opportunities to expand.
Document and share what you’re learning so you’ll have real projects and real results to help
convince others that it works. If they understand your process and how you add value, you become
critical to their success which increases your influence.
You’ll also need to build relationships with influential people who are willing to provide feedback,
pilot new workflows, and champion this new way of working.

Stay ﬂexible
It’s important to avoid being dogmatic about your process. Scrum provides useful guidelines and
tools but should not make you inﬂexible to change.
Each project is different and you’ll have to adapt. If you have a sprint where everyone was gone on
vacation, cancel the retrospective meeting. Only do things that add value. If something doesn’t,
eliminate it.

Continually optimize
You don’t need to get it right the ﬁrst time. You only need to learn and improve over time.
Continually measure performance, gather feedback and optimize.

“As a product team we need a process that can reliably produce
high quality deliverables within a predictable timeframe while
allowing ﬂexibility when new information is introduced.”
I’ve found that adapting Scrum can make your process reliable, predictable and ﬂexible. I used it to increase
my team’s value to the business and build trust with others.
It helped me get a seat at the table and I know it can help you.

Thank you!
linkedin.com/in/tonysmithdesign
@tonysmithdesign

Adapting Scrum for UX Teams

Recommended

Recommended

More Related Content

What's hot

What's hot (8)

Similar to Adapting Scrum for UX Teams

Similar to Adapting Scrum for UX Teams (20)

Recently uploaded

Recently uploaded (20)

Adapting Scrum for UX Teams