IN DEGREE PROJECT COMPUTER SCIENCE AND ENGINEERING,SECOND CYCLE, 30 CREDITS

, STOCKHOLM SWEDEN 2019

Integrating UCD with Agile Methods: From the perspective of UX-Designers

THUJEEPAN VARATHARAJAH

KTH ROYAL INSTITUTE OF TECHNOLOGYSCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

Integrating UCD with Agile Methods: From the perspective of UX-Designers

Master of Science Thesis Thujeepan Varatharajah

tvar@kth.se

Supervisor: Anders Lundström Examiner: Haibo Li

Abstract With the increasing popularity of Agile methods in software development projects, an emerging question is how Agile incorporates user needs to their process – which is the staple of User Centered Design (UCD). Existing reports indicate that integrating Agile and UCD has shown to improve the process and end product and that they are a natural fit. However, there is also a general lack of guidelines of how an effective integration may be done, and further research is requested. This study aims to provide that by portraying some aspects of how Agile and UCD may be integrated in practice, but also some factors that may affect such an integration. This is done through an empirical study, by gaining insights from the perspective of UX-designers who are part of Scrum teams. Ten UX-designers took part in semi-structured interviews, and based on a thematic analysis, results are portrayed in terms of suggested factors to consider when integrating Agile and UCD methods. Sammanfattning Samtidigt som Agila metoder ökar i popularitet inom mjukvaruutvecklingsprojekt, så uppstår även frågan om hur Agilt arbete integrerar användarcentrerade krav i sin process - ett område som är i fokus inom Användarcentrerad Design (ACD). Tillgängliga rapporter indikerar på att integrationen av Agilt och ACD har givit förbättrade processer och slutprodukt, samt att båda processer är kompatibla med varandra. Det anses dock finnas en brist på riktlinjer i hur man kan integrera båda processer, och det efterfrågas vidare studier i ämnet. Denna studie ämnar till att erbjuda just detta genom att presentera några faktorer av hur Agilt och ACD kan integreras i praktiken, men också exempel på faktorer som kan påverka hur väl integration lyckas. Detta tas fram genom en empirisk studie, genom att ta del av insikter från UX-designers som jobbar i olika Scrum projekt. Tio UX-designers deltog i semistrukturerade intervjuer, och baserat på en tematisk analys så presenteras resultat i form av föreslagna faktorer att ta del av när man vill integrera Agila och ACD metoder.

Acknowledgement I would like to show my gratitude towards Anders Lundström and Haibo Li who have provided valuable knowledge and guided me through this work. I also want to show my gratitude towards all participants for setting aside their time, and allowing me to conduct this study.

Integrating UCD with Agile Methods: From the perspective of UX-Designers

Thujeepan Varatharajah

Royal Institute of Technology

KTH

Stockholm, Sweden

tvar@kth.se

ABSTRACT

With the increasing popularity of Agile methods in

software development projects, an emerging question is

how Agile incorporates user needs to their process – which

the staple of User Centered Design (UCD). Existing

reports indicate that integrating Agile and UCD has shown

to improve the process and end product and that they are a

natural fit. However, there is also a general lack of

guidelines of how an effective integration may be done,

and further research is requested. This study aims to

provide that by portraying some aspects of how Agile and

UCD may be integrated in practice, but also some factors

that may affect such an integration. This is done through

an empirical study, by gaining insights from the

perspective of UX-designers who are part of Scrum teams.

Ten UX-designers took part in semi-structured interviews,

and based on a thematic analysis, results are portrayed in

terms of suggested factors to consider when integrating

Agile and UCD methods.

Author Keywords

Agile; Scrum; User-Centered Design; User Experience;

UX-designer;

ACM Classification Keywords

H.5.m. Human Computer Interaction (HCI)

K.6.1 Project and People Management

INTRODUCTION

The Agile methodology for software development projects

has steadily been increasing in popularity, and its

manifesto adheres to a principle of prioritizing the

customer through iterative and continuous delivery of

valuable software. In particular it welcomes changing

requirements, which is in contrast to traditional waterfall

methods. However, for software to be valuable, it may be

argued that it should also be a product that offers a high

degree of usability. This goal is also the staple of a user-

centered design (UCD) approach, which promotes an

iterative process that welcomes changing requirements

based on the user needs to bring forward an optimal user

experience (UX). Consequently, it is also becoming more

common that specialists within UX (UX-designers) are

being deployed in projects to tackle these tasks, which has

also shown to increase the usability and quality of the end

product [1,2,3,4,5,6].

With these aspects in mind, the need to optimally integrate

UCD with Agile methods emerges. At first glance, their

similarities may simplify such an integration as they both

prioritize the user/customer in their stance, and both are

iterative in nature in order to welcome changing

requirements. However, Agile processes do not define a

UX-role and lacks guidelines for how or when such

activities should be conducted making the integration

difficult [6,7].

It is within this spectrum that the study field of Agile and

UCD integration investigates how they should be

integrated. In a systematic review conducted by Silva et al.

[6], they showcase a model where UX-designers and

developers work in parallel with each other, but where UX-

activities lie one or more iterations ahead. The authors also

conclude that whilst there is a growing amount of papers

within this subject, the amount of research is limited and

more empirical studies within this field is needed.

The objective of this research is to perform such an

empirical study from the perspective of UX-designers

working in real life projects in different organizations. This

is to provide further empirical research of how UX and

Agile can be integrated, but also present what factors that

can promote or hinder UX-designers in an attempted

Agile/UCD integrated environment.

PURPOSE AND RESEARCH QUESTION

The purpose of this study is to provide further empirical

research on Agile/UCD integration, but from the

perspective of some UX-designers and how they may

perceive their workflow in an Agile process. Since Agile

methods do not generally define a designer role,

understanding how UX-designers perceive this workflow

may provide valuable insights. This includes

understanding how they work but also what factors that

may promote or hinder integration and the fulfilment of

their role as a UX-designer.

The research question for this study is:

From the perspective of some UX-designers, how is UX-

designers working in Agile processes and what factors may

affect an effective integration of Agile and UCD methods?

Limitations

A limitation to this study is that whilst the research

question aims to present the perspectives of some UX-

designers, the study adheres closely to an interpretivism

paradigm, and the presented content should be noted as

such. This means the study will not be able to present a

single objective portrayal of the UX-designers perspective

on the topic, as the results could be influenced by the

values of the researcher.

BACKGROUND Agile

Agile methods are a class of software development

processes that adheres to a manifesto which asserts its

highest priority is to satisfy the customer through early and

continuous delivery of valuable software [9].

Abrahamsson et al. [10] provides a definition of what may

constitute such an Agile method: ”when software

development is incremental (small software releases, with

rapid cycles), cooperative (customer and developers

working constantly together with close communication),

straightforward (the method itself is easy to learn and to

modify, well documented), and adaptive (able to make last

moment changes)”.

One such Agile method is called Scrum and it aims to

produce increments of a product in a time-boxed and

iterative manner - through iterative cycles called Sprints

[11]. The main roles of a scrum team consists of the

Product Owner (PO), the Development team (DT) and the

Scrum Master (SM). The PO is responsible for managing

a Product Backlog (PB) which contains the product

requirements and their order of priority. The DT is cross-

functional and self-organizing in how to reach the goals set

for that sprint, and the SM has a management role.

The general workflow of a sprint consists of an initial

planning meeting where the PO goes through the top

prioritized features from the PB with the entire team, and

based on input from the DT the Sprint Goal is set for that

iteration [11]. During development, daily meetings are

held to update the team of the progress, and the output of a

completed sprint should be a “potentially releasable

product increment”. The concluding parts of a sprint

include demonstrating what has been done and going

through the PB with the entire team and stakeholders to

adapt it or make changes to the upcoming sprints.

The need for Agile/UCD integration

Agile methods purpose to be adaptable, iterative and with

a focus on customer satisfaction marks some similarities

with UCD which focuses on user satisfaction and also

follows an iterative path that is refined by using empirical

information from previous iterations [4,6]. However,

whilst both aim to produce high quality software, they

approach it from different perspectives. Agile mainly

describe activities for working code (functionality or

features) whilst UCD describes activities for increasing the

usability and user experience of the product [8,12].

Additionally, it should also be noted that the customer is

not necessarily an adequate representative for the users of

the product. As such, the integration of Agile and UCD can

be seen as a complementary approach.

Agile alone is seen to lack an awareness of usability issues,

and the integration of UCD activities into Agile can

improve the product by incorporating ways to evaluate the

needs of end users. Similarly, Agile can aid an UCD

approach by providing a structure to turn design into

working software with an iterative approach that allows for

more frequent usability evaluations. Whilst their

perceptions and priorities may be different, integrating

UCD into Agile can thus offer an improved product with

higher usability. Several reports mention such benefits

including increased product quality and development

processes, as well as improved communication and

collaboration between development and design teams

[1,2,3,4,5,6].

Challenges in Agile/UCD Integration

Agile methods do not define a specific designer role, and

therefore integrating UCD with Agile becomes a

challenge. Specifically, there is a lack of guidelines of how

to establish UX-designer roles in relation to developers

[6,7,13]. This also includes problems of how to coordinate

design activities with development activities and the

synchronization of these. As both are iterative in nature the

timing and scheduling of these activities in relation to each

other is a challenge [5,12]. Additionally, Agile methods

define and measure progress through working software,

and this can also introduce difficulties in how to prioritize

UX-related decisions [8,14].

Another aspect that challenges the Agile/UCD integration

are their views on how resources should be allocated in

terms of upfront design and requirements gathering work.

Agile discourages extensive upfront work in order to be

more adaptable for changing requirements throughout the

process of several iterations. On the other hand, UCD

promotes extensive upfront user research and analysis

prior to development begins in order to gain a holistic view

of what requirements may affect the user experience.

These differing philosophies creates further obstacles of

how to integrate both processes [3,4,5,6].

Related work

Chamberlain et al. [15] conducted an ethnographic study

by studying three project teams with the purpose to

identify issues that may arise in an attempted integration

of UCD and Agile development. Part of their conclusions

were that Agile and UCD are compatible together, but

issues that can cause them to be at odds include:

communication issues and power struggles between

developers and UX-designers, that development takes

more time than creating prototypes, a reluctance from team

members to understand the needs of other elements of the

project, and the rate of user involvement throughout the

project.

Kollman et al. [16] conducted a qualitative study in which

they interviewed UX-designers and observed teams to

understand their role in Agile projects. They identified two

themes that are perceived by UX-designers to be important

for a successful integration of UX and Agile: the UX-

designers understanding of their job role in an Agile

process, and the need to establish and maintain a shared

team vision that contains goals from a technical, business

and UX perspective. Furthermore, Kollman suggests that

UX-designers should become design facilitators and

partake in generating and prioritizing requirements for the

product, and that the use of “lightweight” tools(e.g. paper

prototypes) makes UCD more agile.

Dahl [8] conducted five case studies with different project

teams to observe how Agile and UCD are integrated in

practice. Part of the findings include: all projects had a

longer upfront phase in which overall requirements were

gathered but in which UX-designers were not part of, there

was a mutual understanding between UX-designers and

developers to adapt their processes to support each other,

and that the projects that followed a Scrum methodology

had processes that were similar to the Parallel Track

model (See “Systematic reviews and Parallel Track

Model”)..

Raison et al. [17] conducted five case studies in different

project teams to observe how an attempted integration is

applied in practice, but also to study what factors may

promote and hinder such an integration. Their common

findings include a methodology of UX-designers working

at least one iteration ahead of developers similar to the

Parallel Track model. Furthermore, UX-designers being

co-located with the development team was also regarded

as an important factor for successful integration. A

significant problem with integration was that UX-work

was often seen as an “add-on” and lacked strategic support.

Systematic reviews and Parallel Track model

Silva et al. [6] conducted a systematic review in 2011 on

the topic of integrating UCD with Agile methods and the

three most common artefacts from their referenced

literature include:

1. Little Design Up Front (LDUF) - incorporating

the up-front work related to UCD, before

development begins, but in a much more reduced

manner.

2. Agile/UCD integration improves collaboration

between UX-designers and developers.

3. Using Low-fidelity prototypes in the process.

Based on this and further common findings of their review,

they showcase a variation of a “Parallel Track” model for

how UCD and Agile can be integrated. Whilst several

variations of this model has been presented in both

experience reports, e.g. [3,18] and empirical research, e.g.

[4,8], the model as presented by Silva et al. is detailed here

[6].

The model includes an initial Sprint 0 before development

begins and is supposed to be where initial user research

including clarifying requirements and creating initial low-

fidelity prototypes can be done. Once development begins

in subsequent sprints, UX-designers and developers work

in separate but parallel tracks where UX-designers work at

least one iteration ahead of developers. The reason for this

is that UX-activities such as user research, gathering

requirements, prototyping, usability evaluations etc.

should occur up-front and then be handed on to developers

in subsequent sprints to then be implemented - thus

integrating UCD work into the developed features. During

software development, UX-designers should also provide

feedback on what is being developed in that sprint. The

implemented features may also then also be user tested

and/or evaluated by UX-designers one sprint after

development to raise any issues.

Silva et al. concludes that all of their referenced papers

mention that Agile and UCD are a natural fit and an

integration can work well[6]. However, they also conclude

that there is a need for more empirical studies in this topic,

and that most of their findings were based on experience

reports. This is further corroborated by a subsequent

review conducted in 2014 by Jurca et al.[5], in which they

highlight that there has been an increase in empirical

studies compared to when Silva et al. conducted their

review but that it is still lacking. Jurca et al. also mention

that in the empirical research they reference, they could not

conclude that some core aspects of the Parallel Track

model, including a Sprint 0 and UX-designers working one

sprint ahead, was highly used in practice as per their

research.

METHOD

In order to answer the proposed research question, an

empirical study was performed. The study was done by

conducting semi-structured interviews with 10 UX-

designers (P1-P10) who had current and previous

experience working in Agile projects. The participants were spread across 9 different

organizations and were active in organizations from

Sweden (P1-P6, P9-10) and Canada (P7, P8). The

Canadians was working in the same organization albeit in

different departments. The aim was to gain a wider

spectrum of responses that was not tied to a specific

organizations structure. Respondents P3, P4, P7, P8, P10 all had at least 2 years of

experience working as UX-designers, whilst P1, P2, P5,

P6, P9 all had at least 7 years of experience. All

respondents were currently (or recently) active in working

as a UX-designer in Scrum projects. They all also had

previous experiences working in Agile projects. It should

also be noted that all respondents were specifically

working as UX-designers in their teams - thus not

combining other roles in their projects.

Interviews

Each interview lasted between 45-60 minutes and most

were held face to face (P1-P5, P7, P8, P10), while two was

conducted using video conference calls (P6, P9). They

were of in-depth semi-structured nature, which allowed for

open-ended questions to be used in conjunction with an

interview guide. This allowed the interview to focus on

aspects related to the research question and also making

the participants reflect on each question and allowing for

follow-up questions. This methodology was relevant to

this study in order to gain a realistic understanding of the

complex dimensions that are part of the participants work

process when being part of an Agile/Scrum project.

The interview guide was formed with questions that would

aid in answering the proposed research question, but it was

also supported by a conducted literature study in order to

draw comparisons with ideas mentioned in available

research and experience reports. In particular, when

attempting to understand the general work process of each

participant, a descriptive diagram of the Parallel Track

model [6] was presented in order to find any similarities

and differences to their own workflow.

The interview guide aimed to uncover the following

aspects:

1. A general background of the participant in terms

of their experiences as a UX-designer.

2. Their experience in working with UX-activities in

Agile environments and their latest such project.

3. Their work process as a UX-designer in an Agile

project. What differences are there to the Parallel

Track model. What responsibilities they have and

how and when they perform UX-activities.

4. The relation between UX-designer and

developers but also other members of an Agile

team.

5. Their opinion of Agile processes and whether it

fits an UCD/UX-designers approach.

Each interview had a primary focus on understanding the

process, and their opinions, of the project they are

currently active in, or the latest Agile project they were part

of. However, in cases where it was relevant, the

respondents previous experiences in Agile projects was

also discussed in order to gain more insights.

It should also be noted that since all respondents had their

recent experiences in Scrum projects, the results is biased

towards that Agile process.

Data Analysis

All interviews were recorded, with permission, and later

transcribed in order to conduct a thematic analysis on

them. The aim of a thematic analysis was to identify,

analyze and report emerging patterns and themes within

the data [19]. A thematic analysis was seen as a viable

option to identify patterns that could potentially answer the

research question of how UX-designers may perceive the

integration of Agile and UCD methods. The thematic analysis in this study was conducted by going

through each transcribed interview, finding emergent

themes and organizing them by coding themes and

grouping data of each participant for each theme. This

process was conducted several times in an iterative manner

in order to find common themes across the participants

which forms the results presented in the subsequent

section.

RESULTS

Based on the conducted thematic analysis, six common

themes emerged. These themes cover topics that include

the upfront work done, the workflow during sprint cycles,

relationships between members, and their opinions on

working in an Agile process. The results of each theme is

detailed below.

Upfront Work

The amount of upfront work UX-designers conduct before

development cycles begin was discussed with all

respondents. Most respondents (P1-P3, P5-P9) commented

on an initial phase in which overall requirements are

gathered and understood to produce an initial backlog - and

which may be called the planning phase before the project

officially begins. Many respondents (P2, P3, P5-P8) state

that they had participated in this early phase in their recent

projects, albeit in different measures across the

respondents. process when being part of an Agile/Scrum

project.

As an example of such a planning phase, P2 details a

process in which P2 partakes in an initial analysis with

three other members, to conduct research and gather

requirements - and this occurred before developers and the

rest of the team were brought in. These requirements were

then transformed into user stories and discussed with the

Product Owner in order to produce a “User Story Map”

which was intended to be communicated with the team

before and during the sprint cycles (it is refined during the

sprint cycle process). The user story map was separated

from a scrum board and was intended to provide a holistic

overview of the product and how the user stories tied

together with regards to the user journey, along with their

priority. The intention was that it could then act as a

reference point during the sprint cycles.

“User story map is about where are we heading? [..] User

story map maintains the picture of how everything ties

together. This means when developers work on a story

during a sprint they can already visualize how it ties

together with future sprints” - P2

Respondents P3, P5, P6, P7, P8 also partake in initial

planning phases, starting before the sprint cycles begin,

where they conduct generative research to gather and

analyze initial requirements as well as aiding in

determining and the prioritizing of them in the product

backlog. This is typically done in conjunction with the

Product Owner and other relevant members and

stakeholders.

“When I started in this project, I did a lot of research to

understand different user needs. And that work became a

base for the prioritizations that we started doing, and

which we still do in the project now for upcoming sprints.

Some of these requirements are very far away in the future

and are quite vague so that they can be adapted in the

future.” - P3

P5, P6, P7 also specifically mentioned that they tend to

create high-level designs and iterate towards initial

clickable prototypes (P5, P6) or low-fidelity wireframes

(P7) of the product during this phase.

“First UX does a analysis of the situation. That’s what you

tend to do first. Based on that analysis you start to build

one or more prototypes of the entire product in

conversation with the stakeholders, and this occurs before

development begins”. - P5

Both P5 and P6 expressed that it is important to have a

high-level design before the sprint cycles begin

“I feel that if you are going to design a system it is an

entity. It is very difficult to sit during a sprint X and Y and

only design something isolated, because everything needs

to tie together conceptually. I don’t think you can get a

good user experience like that. You also need to take time

beforehand and work on the wholeness of it” - P6

Furthermore, respondents P6 and P7 specifically mention

that the initial planning phase may also determine whether

a project should move forward or not and thus act as a part

of the product strategy:

“The product team will bring us in early enough so that we

can at least chat about it. Talk to our users and raise an

amount of data that will either help the case or let our

leadership team know that this is the wrong path to go

down” - P7

It should be noted that respondents P2, P3, P5, P6, P7, P8

mentioned that their work in the initial phase (detailed

above) is generally not confined to the length of a single

sprint, i.e. a Sprint 0, but typically done in a longer phase

before sprint cycles and development begins. The time

needed for this was not mentioned by all respondents.

However, P2 mentioned it was a period of three months

whilst the other respondents simply mentioned that it was

a longer phase. The respondents also mentioned sentiments

that they value that UX-designers are part of a planning

process to form the initial backlog, allowing them to

partake in the visioning of the project.

“The projects I like to work the most with are when there

is a focus on analyzing and prototyping in the beginning

before you actually start to develop something [..] This is

where you bring forward a concrete vision of where we are

heading. Then you will adapt it and adjust it once the

sprints with the agile process begins” -P5

In contrast to the respondents above, P1, P4, P9, P10 were

not part of a specific planning phases before the project

officially began. Instead they were introduced through a

Sprint 0 in which initial requirements and goals were

already brought forward by PO and stakeholders (or

including other members). The work conducted in Sprint 0

was then regarded as a pre-work phase to clarify

requirements and/or create new ones based on the initial

visioning, leading to the creation of initial prototypes.

However, P4 mentioned that they have separate

“Hypothesis meetings” in which UX, Product Owners,

Stakeholders and other relevant members from the entire

department partakes to work on a separate backlog of

requirements for how to improve their customers

experience. These user stories can then be feeded into the

roadmap for new projects thus allowing UX-designers to

some extent partake in defining the initial visioning for

new projects.

Respondents P1 and P9 mentioned that the lack of UX-

designers being part of a planning phase is a flaw in their

process.

“My experience is that, especially in larger organizations,

the scope and resources are already set, the amount of

developers, UX-designers and the backlog. It’s only

afterwards that UX-designers are brought in and are

supposed to work a sprint before development. But

shouldn’t we include the UX resources when we are setting

the initial backlog instead? Shouldn’t we evaluate the

needs?” - P1

P9 specifically emphasize an opinion that the stage at

which organizations introduce UX-designers, could speak

of their general maturity in terms of working with UX.

“I believe UX should be introduced from a strategic level

to determine what to build.[..] Many organizations are still

very immature in working with UX, and I would say the

ones that are the furthest behind are ones that introduce

UX-designers at a Sprint 0. Whilst the ones that are more

mature introduce UX-designers from a planning phase”-

P9

P1 and P9 further mentions some issues arising from this

as they have experienced that projects tend to be more

oriented towards reaching feature-focused goals rather

than user-centered goals. P1 also mentioned that this could

lead to work between developers and UX-designers to be

out of sync with each other.

“If you put a UX-designer in a Sprint 0 and ask them to do

user research and conceptual tasks that should be

developed in the next sprint. Then they then start to

question the backlog, and you end up in a situation where

you already start to fall behind.” - P1

P1 specifies that it is not about getting more time to do pre-

work or extending the time of a Sprint 0 in which they can

start work from a provided backlog. The respondent still

mentioned that most of their work was done there. Rather

it is about having user-centered goals in the backlog to

measure on, so that the flexibility to make design-oriented

decisions throughout the project exists. This includes when

setting the initial backlog from the beginning of the

project.

Workflow

When the project team is set and the sprint cycles begin,

all respondents, except P4, mentioned that the intention is

to work at least one sprint/cycle ahead of development

with work to clarify requirements and producing

prototypes to hand over to developers in subsequent sprint.

This work could include contextual inquiry, producing and

iterating on prototypes and user flows, receiving feedback

from developers on prototypes, and user testing on

prototypes.

P2, and P10 specifically mentioned that as a UX-designer

they generally need to be focused on the outcome of three

simultaneous sprints whilst developers could be more

focused on one sprint at a time. This typically include

researching and gathering requirements from two sprints

ahead, designing prototypes for the upcoming sprint and

giving feedback whilst developers are implementing.

However, whilst many respondents (P2, P6, P7, P8, P9,

P10) indicated that they often work 1-2 sprints ahead, how

far ahead all respondents worked throughout a project

could vary depending on the estimation and sprint

planning.

“Usually we work one to two sprints ahead. But sometimes

if it’s something bigger we might even start to work 3-4

sprints ahead because there is a lot that the UX and

requirements people will have to do”. -P6

P4 was the only respondent who mentions that in their

current project they often work in the same sprint as

developers where they aim to provide prototypes early in

the sprint that gets implemented within the same sprint.

However, they may also work ahead of development with

what they call “explore stories”, which may involve a UX-

designer to produce data for future sprints. However, when

explore stories are conducted, it is usually in conjunction

with user stories for that sprint. Furthermore, the

distribution of work between user stories and explore

stories can vary. P4 exemplified this by saying that in a

two-week sprint the first few days might focus on

providing prototypes on user stories to the development

team, and the rest of the sprint might focus on explore

stories whilst also being available for feedback and

usability testing for the developers.

Time estimation for working ahead All respondents said that they generally have sufficient

time to stay ahead (or in parallel in the case of P4) in their

current projects. However, P7 and P10 mentioned that it

can be difficult to estimate the time for UX-related work

which can challenge staying ahead. P10 also mentions an

opinion that the challenges with time estimating could be

improved if previous experiences for UX-related tasks

would be made more visible.

“I think there should be some work done to estimate UX-

work better based on previous experiences. Not just to see

that a user story took more time than anticipated, but more

specifically what kind of UX-related tasks that took more

time. So that we can use that knowledge for upcoming

sprints” - P10

Additionally, P7 and P4 mention that they have had

experiences where they have been assigned to many

different projects or products, which can be a challenge

when trying to work ahead. Hence they also mentioned that

UX-designers should preferably be able to be focused on

one product or project rather than being assigned to

several.

Prototypes & User Testing

A common comment amongst most respondents (P1-P8)

was that the prototypes provided to developers need to be

closer to high-fidelity rather than low-fidelity as this often

leads to a better understanding for developers of what to

do. The use of wireframes and lo-fi prototypes was

mentioned by some respondents (P2, P4, P5, P6, P7,

P8) as an initial starting point that could be used when

working internally with clarifying requirements in the

upfront phase and/or during the sprints to then be iterated

on - but that delivery to developers need to be closer to hi-

fi.

“The closer you are to high-fidelity, the more satisfied

developers are. However, when working with clarifying

requirements it can be of more low-fidelity so that you

don’t focus too much on graphical parts like color etc. But

once you deliver to developers, you need to be ready to

hand over something of more high-fidelity. You can’t just

hope for the best and expect developers to understand low-

fidelity sketches in the same way you do” -P2

In terms of user testing, many respondents (P3-P8)

mention that it is often conducted on high-fidelity

prototypes initially, although it may also occur on

implemented versions at later stages. How often testing

occurred was varied between the projects and respondents,

as no one mentioned testing to occur during or after each

sprint. Some respondents (P2, P3, P4, P5) mentioned that

testing was fully or partially done by other dedicated

members of the team or outsourced, and P8 specifically

mentioned the lack of a dedicated tester in their team as a

flaw because it leads to doing less user testing than what is

desirable.

“If we do testing it’s very minimal. I’ll do it before locked

[finished] designs, by getting some feedback from

customers and then changing things based on that. But for

projects we normally make a lot of assumptions[..] I would

love to do more user testing but we don’t have someone

dedicated to it so it’s hard for us to do because there is

already so much other things to do in two weeks[sprint

length] and often it’s not enough time” - P8

Relationship with Developers

As mentioned in the method, the collaboration between

UX-designers and developers was discussed with all

participants. Most respondents (P1-P5, P7-P10)

specifically emphasized that they would want more

consistent communication between developers and UX-

designers throughout the sprints. This is important to both

discuss prototypes and offer feedback during development

in order to gain a mutual understanding of technical

constraints and UX requirements.

“I think it is important to involve developers from early on.

So that I also design effectively and become aware of

technical constraints and opportunities. But also to

communicate with them continuously when they implement

it, so that we don’t become isolated to each other.

Otherwise, if they ask me something about the design after

a while, I might have forgotten it since I worked with it

during the previous sprint. But that’s not how it should be

so continuous communication is important” - P10

Whilst continuous communication was highlighted by

many respondents, some factors were mentioned which

could affect the collaborative nature, and these are detailed

below.

Being Co-located

Most respondents (P1, P2, P5-P10) have been co-located

with the developers in their recent projects. P2 mentioned

that the use of a user story map alleviated the

communication between developers and UX-designers

because it was always physically available in the

workplace and created a better understanding for

developers of relationship between features that are being

developed and upcoming ones. P2 also expressed that

upcoming user stories and designs were discussed with

developers to determine technical feasibility but added that

UX-designers should seek communication with developers

during development as well.

“As we sit close to the developers I am able to see whilst

they are working on something and see if there are

disparities from what was intended from the UX-side. If so,

we can discuss and they can fix it directly, and the

developers are also good at checking with us[...] You need

to take space as a UX-designer. If the communication is

missing be the one that communicates” - P2

Respondents P5, P7, P8, P9, P10 also expressed similar

sentiments and that being co-located with developers can

make it more convenient to have continuous

communication both when working on a design and when

it is being developed.

“Usually our intent is for the designers to be embedded

within the teams. So that there is constant communication

and we’re not only designing in a bubble where they can’t

carry out something from a code perspective or vice

versa” - P7

P8 gave an example of how they improved their process by

introducing scheduled “brainstorming sessions” early on

in a sprint where UX-designers and part of the

development team take part to discuss early prototypes

both from a technical perspective and UX perspective.

However, in addition to a scheduled session, being co-

located aids in having continuous communication when

needed.

“The brainstorm is normally when I first receive feedback

from developers. For instance, there was something I was

working just a little while ago where they thought the flow

was a little bit weird. So between brainstorm and the final

stages of the sprint, I had a lot more communication with

them and they sit close by so it’s easy.” - P8

Not being co-located

P3 and P4 were the only respondents that mentioned to not

be co-located with the developers in their recent projects.

P4 expressed that they generally felt that communication

during the sprint worked well and also expressed that it is

important for developers to understand the role of UX and

also give continuous feedback on designs, in addition to

the technical feedback.

P3 also mentioned that they discuss designs that they are

working on during the sprint, but that feedback was mostly

from a technical perspective to understand what is

technically feasible. However, P3 also expressed that not

being co-located meant it is more challenging to have fluid

feedback whilst a provided prototype is being developed.

“It can happen sometimes that prototypes I provide don’t

take the same form in production, with smaller details

differing. What I could wish for is that if we were working

at the same place, then we could communicate and provide

feedback more fluidly. Now, it is a slight effort to check if

someone has time and then call them, and so the work flow

can feel a bit stiff sometimes. Like, I create prototypes, talk

to them, they develop it and then I get to look at it

afterwards” - P3

P5, who has had previous experiences working with

offshore developers, expressed similar sentiments that it

can create a bigger separation between UX-designers and

developers, especially if the developers are not used to

working with UX-designers before.

Understanding & Mindset

Some respondents commented on the level of

understanding that developers might have of the role of

UX, as a factor that could affect how well the collaborative

nature between developers and UX-designers

becomes(P1,P3,P4,P5,P7,P8).

P5 mentioned that it is important for developers to

understand that design is also an iterative process that will

continually evolve and change. P5 also mentioned that in

their experience many developers do not have that mindset

and rather want to be handed a design and then be done

with it.

P7 also expressed similar sentiments but with a focus on

some developers not wanting to work as collaboratively:

“I’ve worked with great developers which I’ve had back

and forward communication with[..] But I’ve also had

other developers who were like ‘you do your work and

when you’re done give it to me and I will do my thing. And

if I cannot, you will have to figure something out’. We tend

to fight back a lot in those cases and we continually strive

to make things more collaborative”. -P7

P8 mentioned that in their current project they work quite

collaboratively, but P8 have also noticed other teams in

their organization where developers seem to want to work

more separated.

Another aspect P7 mentioned was that generally

developers might have a different way of thinking than

designers and gave an example of a challenge this may

present where developers give feedback that are based on

their own perspective, rather than being open for new ideas

and letting the users drive the decisions. P1 expressed a

somewhat close sentiment that in “engineering-focused”

organizations it is more common that they receive

feedback from developers of something not being feasible.

However, P1 also believes this is a result of the product

backlog and requirements being too feature focused (rather

than considering user-centered goals) thus giving less

room for flexibility in UX-related decisions.

Relationship with Product Owner

All respondents talked about a continuous relationship

with the PO throughout the project. In this context, some

respondents (P1, P2, P3, P4, P8) specifically mention that

it is important to have a PO that values the importance of

UX, as that tends to allow user needs to be more valuable

in the project. Furthermore, the respondents mention that

there can be conflicts of interests with a PO that is more

focused on other perspectives (technical or business

perspectives were mentioned) whilst undermining

usability factors.

“I think one of the key factors to integrate UX and Agile is

to have a PO that understands the need and role UX.

Because I’ve had previous experiences with PO that are

more focused on getting products and features out rather

than promoting and understanding the need to focus on

producing more user value in the products.” - P4

P1 specifically emphasize that a closer collaboration

between UX-designers and PO can be important to

incorporate requirements into the project that have been

validated.

“I think the PO and UX needs to be working closer with

each other. In my experience PO is often more technical,

but if the PO understands the value of validating ideas then

we will also have requirements in the backlog once they

have a clear worth” - P1

Opinions on Agile

When asked about their opinions on Agile methods and

working with UCD and UX-related activities in an agile

process, almost all respondents (P1-P4, P6-10) were

positive. Many respondents (P2, P4, P6, P7, P8, P10)

emphasize aspects of Agile that supports close

collaboration between different members of a project.

“Once you’ve done the upfront discovery work and start

working in sprints I think Agile is great. Because for

instance you can collaborate with developers much more

at that moment in time[...]If design was instead to figure

everything out and then passing it off to development, then

issues come up later and it’s a lot of rework”. -P8

P4 further exemplifies that Agile also allows them to

collaborate with decision makers to affect the projects

path.

“When working agile, I’ve experienced that you work

much closer to the people who are responsible for the

decisions. This also means that I can get my deas through

more effectively. For instance. I work near our

stakeholders and it makes it much easier to get my visions

incorporated throughout the project” - P4

Furthermore, the respondents also highlighted how Agile

allows for requirements to be adaptable which aids the

UX-process.

“I’m very positive to working Agile. It requires more work

but the end result becomes much better. It allows people to

gain knowledge throughout the project which they can

implement to the end product. It is rare that you in the

planning phase already know everything. Instead new

things will come up, and you can now refine it during the

projects lifespan. -P6

P3, whilst being positive towards Agile, also mentioned

that the lack of guidelines of how to incorporate UX-

activities to Agile brings challenges and exemplified this

in how P3 initially had scheduled sessions to motivate to

developers their role and try to suggest how to incorporate

their role to the work process.

In contrast to other respondents, P5 provided some

sentiments of not preferring to work in an Agile process.

P5 was mainly critical towards time-boxed methods in

Agile, e.g. Scrum, and expressed that such processes

hinder a fluid workflow.

“For instance, if we decided that something should be

done in a sprint, and then realize that we will not be able

make it - then suddenly the team starts losing

motivation[..] And you have the opposite as well, you over-

estimate and what do you do then? I think Agile in that

sense is not very suited to a more fluid or effective

workflow.[...] Sprints feel more like a tool for project

leaders to have control.” - P5

P5 also expressed opinions that Agile methods can be very

rigid, in how it in practice wants to deliver something

specific after each sprint and thus may not be that suitable

for iterative design development.

Summary of most common findings

The table presented below summarizes the most common

findings, categorized under each theme that emerged from

the thematic analysis and further reports the frequency of

respondents mentioning them. It should be noted that the

table does not outline all findings but rather includes topics

where the frequency was at least five respondents - with

one exception being under the Upfront Work theme where

the table also shows how many respondents indicated to

start from a planning or pre-work phase in their recent

projects.

Theme Frequency

Upfront work

Starts from Planning 6

Starts from Pre-work(Sprint 0) 4

Preference to start from planning 8

Workflow

At least one sprint ahead 9

Prototypes & User testing

Hi-fi prototypes to developers 8

Using lo-fi prototypes during the

requirements phase 6

Initial user testing on hi-fi prototypes 6

Relationship with developers

Need for continuous feedback during

prototype and software development stage 9

Co-location can improve communication 8

Developers understanding of UX can affect

collaboration 6

Relationship to PO

PO that understand and values UX 5

Opinions on Agile

Positive 9

Close collaboration 6

Adaptable requirements 6

Table 1: Table indicating the most common factors

mentioned by each respondent categorized under the

six themes that emerged from the thematic analysis.

DISCUSSION

As per the research question, the purpose of the study was

to investigate how UX-designers may perceive their

workflow in an Agile process. This includes understanding

cases of how they work and what factors they value to be

important in such an integration, but also the contrary of

what may create issues or challenges.

An initial starting point from the results is that almost all

participants of the study had a positive opinion of working

as a UX-designer in an agile development process. In

particular it was highlighted that agile methods has the

premise of introducing closer collaborations between team

members, allowing UX-work to be more effectively

integrated to the project. This is coherent to Silva et al.

review where improved collaboration between UX-

designers and developers were amongst the most common

artefacts of UX/Agile integration. Additionally, it should

be noted that in this study respondents also indicated that

it allows for closer collaboration with other members and

parties of the project, e.g. PO and stakeholders, which are

further valuable reasons for integrating UCD with Agile.

As detailed in the background, a conflicting concept

between Agile and UCD is how much upfront work should

be conducted before software development begins. In Silva

et al. review they mention Little Design Up Front as a

common artefact and portray it in their parallel track model

with a Sprint 0, and in this study all participants mentioned

the existence of a Sprint 0. However, an important

distinguishment should be made on what constitutes the

initial upfront phase and when UX-designers are

introduced at first. Two cases, based on the results, are

provided below.

1. Pre-work: UX-designers and the project team

start working from overall requirements that has

been provided to them by e.g. POs and

stakeholders. Work starts from Sprint 0 in which

UX-designers are tasked with supporting in

clarifying requirements for upcoming sprints and

performing UX-related work.

2. Planning: UX-designers are part of a longer

project planning phase where they together with

POs and other relevant parties aid in setting the

overall requirements and perform UX-related

work as part of this. This phase may start before

the team is set, and before the project officially

begins. It is generally longer than the timeframe

for a single sprint. This also leads to the start of a

project and sprint cycles(which could also include

a sprint 0) with the now assembled project team.

The second case would arguably be more preferred from a

UX-designers perspective since it allows user needs to be

incorporated into the products visioning right from the

beginning. The results from this study also support this,

since almost all respondents mentioned similar sentiments.

Furthermore, six respondents in this study mentioned that

they have been part of such planning phases in their recent

projects, indicating that it may have become more common

for organizations to introduce UX-designers in a project

planning phase. This could also suggest that more

organizations are willing to introduce UX aspects from an

early strategic viewpoint. These results are in contrast to

Dahls study [8] where they observed that UX-designers

were not part of the planning phase in the five cases studies

they performed prior to 2013. However, while much may

have happened in this area since their study, one should be

cautious in drawing too general conclusions based on the

small sample of this study.

It may be argued that a project planning phase as above

should not be regarded in terms of an agile context - as it

may bring forward elements of a waterfall approach. The

official Scrum Guide, for instance, doesn’t mention the

existence of planning phases (nor does it mention the

existence of a Sprint 0 for that matter). However, in

practice it seems plausible that there is an initial period

where the project is being planned in terms of scope,

resources and budget. Whether this is seen as a project in

itself, or part of strategic management, the existence of

such a phase in some kind is at least supported by the

respondents in this study. By including UX-designers in

the process of setting the initial requirements and vision of

it, the project is also set up for inducing user needs from

the beginning, as well as taking advantage of the UX-

designers role. Furthermore, this may also lead to a better

understanding of UX-aspects throughout the project team

since UX-factors becomes a core requirement for the

products strategy.

It should also be noted that UX-designers should not only

be included in this context in the beginning, but also

getting space to partake in it during the lifetime of the

project, i.e. being able to affect the requirements and their

prioritizations throughout the project. In this aspect, agile

methods such as Scrum support UCD since it has dedicated

spaces for the entire team to adapt the requirements

throughout the project. It should also be emphasized that

since the PO (in Scrum) is the one responsible for

maintaining the Product Backlog, the relationship and

workflow between the PO and UX-designer becomes an

important factor to integrate UCD to the process. The

results of this study also support this, since many

respondents mentioned the value of a continuous

relationship with the PO, and that a PO that has a higher

understanding of UX can be a beneficiary factor.

In terms of the synchronization of design and development

activities during the project, the results of this study concur

in many ways with the version of the Parallel Track model

presented by Silva et al. [6]. In particular, almost all

respondents mentioned that they worked at least one sprint

ahead of development with work to clarify requirements

and iterating on prototypes, as well as communicating with

developers during development. However - whilst the

results indicate that it is common to work one sprint ahead

with prototypes and two sprints ahead with research - the

results also showed that this is not always as rigid and it

may require more flexibility, i.e. that UX-designers might

have to work even further sprints ahead. How teams and

UX-designers may plan such a workflow in practice, was

not uncovered in this study. However, this may suggest the

need for teams to develop frameworks to more effectively

estimate the time for UX-designers work, and two

participants also mentioned that they find it difficult to

estimate the required time for UX-related work. One

aspect that was different to Silva et al. model was that that

this study could not conclude that UX-designers would

validate the implemented code from the previous sprint.

Instead the results suggest that feedback on the

implementation was often done in the same sprint. This

could be because of an assumption that implementing

changes to already coded features takes more time - thus

focus should be on providing feedback while it’s being

implemented instead.

Whilst it is important to allow UX-designers to incorporate

user needs to the projects vision - as discussed further

above - it is also important that UX-work is communicated

effectively and continuously within the team. This include

a shared understanding with PO and stakeholders (and

other relevant members), but also with the developers of

the team. The need for continuous communication between

developers and UX-designers was also highlighted in Silva

et al. parallel track model, although it mainly puts an

emphasis on UX-designers providing feedback once

developers starts implementation [6]. Most of the

respondents in this study expressed an importance of

communicating with developers both when

working/iterating on prototypes but also whilst it is being

implemented. This is both for the sake of UX-designers

and developers to give and receive feedback, but also to

promote a shared understanding between the parties in

terms of technical feasibility and understanding of the UX.

This can occur both through scheduled sessions, but also

ad hoc during the process. Furthermore, many respondents

suggested that UX-designers should be active in seeking

communication with developers, indicating that it may be

an important factor to be aware of in the UX-designer role.

The results in this study suggest that being co-located with

developers eases the possibility for continuous

communication, which is coherent with the findings of

Raison et al. study[17]. Three respondents in this study had

experience working with offshore developers, and two of

them indicated this could limit the amount of effective

communication and create a larger separation between the

two parties. However, due to the limited amount of

respondents in this regard, it may not be viable to draw any

drastic suggestions of how big of a problem this stipulates.

Another aspect that emerged from this study, was that the

understanding developers might have of the role of UX can

affect the collaboration between both parties, and this is

coherent with some of the findings of Chamberlain et al.

study[15]. It would be interesting in future studies to

understand how such issues can be mitigated. One

suggestion could be the use of a User Story Map, as

detailed by one of the respondents in this study. A User

Story Map could showcase how different features of the

product are connected from a user-centered perspective

and based on user needs - thus increasing the

understanding of UX across the team.

Limitation and Discussion on Method

The conducted study was aimed to follow a qualitative

approach in which semi-structured interviews were being

held to capture aspects that could answer the proposed RQ.

This approach allowed the conducted interviews to have

some structure, whilst also allowing the participants to

express ideas and opinions in an open-ended fashion which

was beneficiary for this study. However, one aspect that

should be mentioned was that some of the interviews

became more emphasized on certain topics as the

participants were inclined to discuss them more. This also

meant that not every aspect presented in the results was

discussed with each respondent. Thus, one should be aware

that if a participant is not referenced in the results, it does

not necessarily mean that the respondent did not agree - as

it instead could mean that it just was not discussed with

that participant.

The specified target group of respondents was decided as

UX-designers who solely work with that role in Agile

projects, and have them be from as many different

organizations as possible. This resulted in 10 participants

from 9 different organizations. The intention was that this

methodology would allow the conducted thematic analysis

to produce results from a UX-designer viewpoint, as well

as not being biased towards a selected few organizations

and their organizational structure. Instead a more general

overview of UX-designers perception of how they work

and what important factors there are in an Agile/UCD

integration could be given. However, there are some

aspects of this approach which could have been improved

in order to get better results.

One such factor is that there was not any particular

consideration done to whether the type of projects the

respondents were part of could affect the results. This was

neither done when recruiting interviewees nor when

analyzing the results. The types of projects in this study

varied from developing whole new products to

maintenance or partial new development of existing

products. There was also a variation in terms of whether

the product was for commercial use or for internal use

within an organization. Such factors and differences could

affect the way the project team is set up and therefore also

the results in this study. An improvement of the method

could thus be to target UX-designers working in specific

field of projects to get more viable results for that field.

Another factor that could have affected the results in the

study, is that the Parallel Track model was shown to each

respondent before asking them to brief the structure of how

they work. This was done as a way to drive the interview,

since there was an assumption that it would be difficult for

the respondents to explain their work process. However,

showing the model could have skewed their responses in a

way that might not have happened without having a model

for reference. A remedy for this could have been to present

the model after they had presented their own process.

Future research

For future studies one can research how organizations in

practice could include UX-designers from a project

planning phase. Whilst this study has provided cases of

UX-designers being part of such a phase, it did not delve

deeper into the factors of how UX-designers co-operate

with PO, stakeholders and other relevant parties during this

initial phase. A study focusing on how these parties can

work together before the development project officially

begins can be interesting for anyone seeking to involve

UCD from a strategic phase.

Another topic that could be interesting to research is what

kind of artefacts and methods can be used to improve the

communication and understanding between UX-designers

and developers. Whilst this study emphasizes the need for

continuous communication between the two parties, and

advices UX-designers to seek communication, it would

also be interesting to delve deeper into some practical ways

of how this can be done. As discussed earlier, a User Story

Map could be one such example, and further studies could

delve deeper into more such artefacts or methods.

Finally, further empirical research should be conducted in

the topic of Agile/UCD integration. Whilst this study

focused on gaining insights from the perspective of UX-

designers, it would be viable to to conduct studies with

other parties of an Agile team as well.

CONCLUSION

The study was conducted in order to answer the proposed

RQ: From the perspective of some UX-designers, how is

UX-designers working in Agile processes and what factors

may affect an effective integration of Agile and UCD

methods?

Based on the conducted study and thematic analysis, the

following are a summary of findings in respect to the RQ,

and may be regarded as suggestions or factors that can be

considered for integrating Agile and UCD processes:

• Introducing UX-designers from a project

planning phase - where they can aid in setting the

initial PB and vision of the project - may aid in

making use of a UX-designers role fully and

inducing user needs to the project from the

beginning. Thus, it may improve an integration of

Agile and UCD.

• During development, UX-designers can follow a

workflow where they work at least one sprint

ahead of development with work to clarify

requirements and produce prototypes to hand

over to developers in the subsequent sprints. This

can typically be working 1-2 sprints ahead, but

may require more flexibility in terms of how far

ahead.

• Low-fidelity prototypes may be used at an initial

stage whilst understanding and clarifying

requirements internally. However, when

delivering to developers, using high-fidelity

prototypes may ease the discrepancies between a

designers intention and what is being

implemented.

• A shared understanding between UX-designers

and developers can be aided if they are in

continuous communication throughout the

project. This includes UX-designers getting

feedback on prototypes from developers, but also

giving feedback to developers whilst it is being

implemented to avoid ambiguity. In practice, this

may require UX-designers to facilitate a

responsibility to seek communication with

developers throughout the project.

• A mutual understanding between UX-designers

and developers in regards to their respective

needs can improve the process. This can be in

terms of UX-designers understanding the

technical feasibility from developers standpoint,

but also for developers to understand the role and

function of UX and how UX-designers work and

what they produce.

• A PO that is aware of UCD, its goals, and values

it equivalently to the technical and business

perspectives of a project can be an important

factor for integration of Agile (Scrum) and UCD.

This may allow a UX-designers work and UX-

related factors to be more effectively integrated

and considered for the project and the PB.

Finally, as indicated by most respondents of this study,

Agile and UCD can be compatible as they share many

ideas in terms of an iterative/adaptable workflow and

allowing team members to work closely together.

Incorporating the above mentioned factors (including

further findings mentioned in the results) may improve

such an integration and allow the project to gain the

benefits of an improved user experience in the end product.

REFERENCES

1. McInerney, P. and Maurer, F. UCD in agile projects.

interactions 12, 6 (2005), 19-23.

2. Hussain, Z., Slany, W. and Holzinger, A.

Investigating Agile User-Centered Design in Practice:

A Grounded Theory Perspective. HCI and Usability

for e-Inclusion, (2009), 279-289.

3. Sy, D. Adapting usability investigations for agile user-

centered design. Journal of Usability Studies 2, 3

(2007), 112-132.

4. Fox, D., Sillito, J. and Maurer, F. Agile Methods and

User-Centered Design: How These Two

Methodologies are Being Successfully Integrated in

Industry. Agile 2008 Conference, (2008).

5. Jurca, G., Hellmann, T. and Maurer, F. Integrating

Agile and User-Centered Design: A Systematic

Mapping and Review of Evaluation and Validation

Studies of Agile-UX. 2014 Agile Conference, (2014).

6. Silva da Silva, T., Martin, A., Maurer, F. and Silveira,

M. User-Centered Design and Agile Methods: A

Systematic Review. 2011 AGILE Conference, (2011).

7. Salah, D. A framework for the integration of user

centered design and agile software development

processes. Proceeding of the 33rd international

conference on Software engineering - ICSE '11,

(2011).

8. Dahl, A. Agile/UX Integration: how user experience-

related practices and processes are integrated with

Agile development processes in real-world projects.

2012.

9. Manifesto for Agile Software Development.

Agilemanifesto.org, 2019. https://agilemanifesto.org/.

10. Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta,

J. Agile Software Development Methods: Review and

Analysis. Proc. Espoo, (2002), 3-107.

11. Schwaber, K. and Sutherland, J. The Scrum Guide.

2017.

12. Ferreira, J. Agile Development and UX Design:

Towards Understanding Work Cultures to Support

Integration. Progress in Pattern Recognition, Image

Analysis, Computer Vision, and Applications, (2012),

608-615.

13. Kuusinen, K., Mikkonen, T. and Pakarinen, S. Agile

User Experience Development in a Large Software

Organization: Good Expertise but Limited Impact.

Human-Centered Software Engineering, (2012), 94-

111.

14. da Silva, T., Silveira, M., de O. Melo, C. and

Parzianello, L. Understanding the UX Designer’s

Role within Agile Teams. Design, User Experience,

and Usability. Design Philosophy, Methods, and

Tools, (2013), 599-609.

15. Chamberlain, S., Sharp, H. and Maiden, N. Towards a

Framework for Integrating Agile Development and

User-Centered Design. Extreme Programming and

Agile Processes in Software Engineering, (2006),

143-153.

16. Kollmann, J., Sharp, H. and Blandford, A. The

Importance of Identity and Vision to User Experience

Designers on Agile Projects. 2009 Agile Conference,

(2009).

17. Raison, C. and Schmidt, S. Keeping User Centered

Design (UCD) Alive and Well in Your Organisation:

Taking an Agile Approach. Design, User Experience,

and Usability. Design Philosophy, Methods, and

Tools, (2013), 573-582.

18. Budwig, M., Jeong, S. and Kelkar, K. When user

experience met agile. Proceedings of the 27th

international conference extended abstracts on

Human factors in computing systems - CHI EA '09,

(2009).

19. Braun, V. and Clarke, V. Using thematic analysis in

psychology. Qualitative Research in Psychology 3, 2

(2006), 77-101.

www.kth.se

TRITA -EECS-EX-2019:519