Category Archives: Agile

Responsibilities and Challenges of Product Owners

Working as a leader in agile is challenging. You need to find a balance between being the authoritative leader and being that supporter of the teamwork. A few years ago we did a study to try to understand the products owners and their work, looking at the following questions: .

  1. What are the main responsibilities of the Product Owners
  2. What are the challenges of a Product Owner, and how does he or she cope with them?

What did we find? 

  • Most of the product owners found it hard to measure the value when developing new features
  • Some Product Owners use the number of users as their main parameter of success
  • To lead the vision was a difficult responsibility that the Product Owners struggled with

The abstract of the paper:

In Scrum, the Product Owner (PO) role is crucial for the team to be successful in developing useful and usable software. The PO has many responsibilities and challenges, including being the link between customers, other stakeholders and their development teams. This exploratory case study conducted at the software development company Spotify focuses on POs three responsibilities: (a) Identification of customers, (b) Estimation of value of their teams’ work and c) Forming a vision for the product. Additionally, challenges perceived by the POs are studied. Data was gathered through five interviews and on site observations. Results show that the POs activities are divided between daily work, such as making sure that their teams are functional and long-term activities such as making a vision for the product. The main challenge of the POs is to inspire and encourage team members to collaborate and communicate within the team and with stakeholders.


 You find this paper and research gate if you’re interested in reading it.

Continuous Improvement and Agile

One can claim that Agile development has positive attitudes towards continuously improving work practices of IT professionals and the quality of the software. There is a clear focus on learning and teamwork, as well as communication in Agile.

A few years back we did a study on Agile with a focus to understand continuous improvement and how it works in practice.

This study focused on value adding activities such as user involvement and gathering metrics. We also looked at non-value adding activities, such as correcting defects.

Interviews were conducted with 10 IT professionals working with agile development in Iceland.

Results show that IT professionals emphasise communication with users both through direct contact and using email. Results also show that they rarely use metrics to make improvements measurable. One can wonder why this is the case in the ara of New Public Management when everyting needs to be measured to be visible?

You find more about this in our paper:

Lárusdóttir M.K., Cajander Å., Simader M. (2014) Continuous Improvement in Agile Development Practice. In: Sauer S., Bogdan C., Forbrig P., Bernhaupt R., Winckler M. (eds) Human-Centered Software Engineering. HCSE 2014. Lecture Notes in Computer Science, vol 8742. Springer, Berlin, Heidelberg

A Licence to Kill – On Agile and Software Development

One can conclude that uses centred systems design (UCSD) has much to gain when integrated into Agile systems development. Agile is the de facto Standard of systems development whereas UCSD is it not at all as commonly used. However when looking into the UCSD activities in agile processes in practice one can see that this integration it’s not that easy.  In a paper by Jan Gulliksen, Marta Larusdotter and me we therefore conclude that UX professionals need a more explicit role and more authority when working in the agile projects.

We have contacted numerous interviews studies and survey studies on agile and UCSD, and we decided to bring together all these published studies together with additional experiences to make some general conclusions about agile and UCSD.

Research method

No of participants

Study 1 (S1)


82 IT professionals in country 1

Published paper: Larusdottir et al. 2009 – [37]

Study 2 (S2)

Survey and interviews

25 IT professionals from 18 software companies working on Scrum projects in country 1 in the survey, 6 IT professionals in interviews

Published paper: Larusdottir et al. 2010 [33]

Study 3 (S3)


49 IT professionals working in Scrum projects mainly in country 2

Published paper: Jia et al. 2012 [29]

Study 4 (S4)


21 IT professionals interested in usability and UX in country 2

3 Published papers: Cajander et al. 2013, Larusdottir et al. 2012, Larusdottir et al. 2014 [11, 34, 35]

Study 5 (S5)


10 IT professionals in country 1

Published paper: Larusdottir et al. 2014 – [36]

Table : An overview of the studies that are analyzed in the paper presented in this blog post.


In the paper we analyse how findings according to th for values presented in the agile manifesto To understand the constraints that the scrum process imposes.

Based on our theoretical analysis on UCSD and Agile, the studies analyzed and the experiences gained we would like to suggest the following general guidance to projects adopting an agile methodology, such as Scrum, that has the goal to focus on usability and UCSD, sorted under the respective heading:

Individuals and Communication

  1. Define the responsibility for Usability and UX for all roles; team members, Scrum master and PO.
  2. Team members responsible for Usability and UX should regularly have face-to-face communication with the actual users and at least once during each sprint.
  3. Team members should make use of multiple channels for feedback, such as social media, user forums or tweets to include the users in parallel with face-to-face communication

Working software

  1. State a clear vision for Usability and UX in an early phase and refer back to it regularly to check, if it should be changed.
  2. Define measurable goals for Usability and UX and evaluate regularly with users, if the goals are met

Customer collaboration

  1. In evaluation with users, it should be checked if the system fulfills the user requirements.
  2. Evaluations should be conducted regularly to measure how satisfied the users are and how valuable the software is for them – at least every second sprint.
  3. Give the person responsible for evaluating Usability and UX a mandate to influence the subsequent project planning – Give them “License to kill”!
  4. A communication plan should be established, for the PO, Scrum master and the team to understand the results of the evaluations.
  5. The result of the evaluation needs to lead to measures that must be commissioned and followed up.

Responding to change

  1. Define themes for the retrospective meetings and make improving the Usability and UX as one of these themes.
  2. Prioritize change requests from users highly, that support a competitive advantage for the users perspective.

If you want to know more you find the paper here:

Larusdottir, M., Gulliksen, J., & Cajander, Å. (2017). A license to kill–Improving UCSD in Agile development. Journal of Systems and Software123, 214-222.

The User’s Perspective in Scrum Projects

Scrum is seen by many as user centred, but how does it really work in practice? Me and Marta Larusdottir set out to investigate this question through an interview study with 21 people who worked with usability in Scrum projects. Marta came from the field of usability evaluation, and she was especially interested in what usability techniques they used in industry.

When we started doing the interviews we were really surprised to find out that the answer to the question: “What usability techniques do they use in practice?” is that there are very few formal evaluation methods that are used at all, and that the methods used are indeed all very informal. The user perspective in Scrum Projects in Practice was indeed only existing, and not explicit.

Conclusions from this study are also that the responsibility for the user perspective is very unclear in Scrum projects. Often the user perspective is neither discussed nor described in the projects. However, the user perspective is often present through informal feedback used to understand the context of use and inform design.

You find these results in this study:

Åsa Cajander, Marta Larusdottir, Jan Gulliksen. Existing but Not Explicit – The User Perspective in Scrum Projects in Practice. Paula Kotz´e; Gary Marsden; Gitte Lindgaard; Janet Wesson; Marco Winckler. 14th International Conference on Human-Computer Interaction (INTERACT), Sep 2013, Cape Town, South Africa. Springer, Lecture Notes in Computer Science, LNCS-8119 (Part III), pp.762-779, 2013, Human-Computer Interaction – INTERACT 2013. .

What Usability Methods are Used in Scrum Projects?

There are a whole bunch of usability methods out there, and we teach many of them in our courses. However, one can wonder what methods are really used the context of Scrum?

We investigated this question in the paper:

Jia, Y., Larusdottir, M., & Cajander, Å. (2012). The usage of usability techniques in scrum projects. Human-Centered Software Engineering, 331-341.

Not surprisingly the most used method is “Workshops” according to the survey we sent out. The second most common method was lo-fi prototyping. The most commonly used usability technique in Scrum projects is workshops, followed by lo-fi prototyping, interviews and meetings with users, all used by more than half of the participants.You see the whole table from the paper below:

How many have used each method.png

The technique that is most frequently used is lo-fi prototyping used by more than half of the participants two to four times a month.

When we asked practitioners what is the best usability method they answered that formal usability evaluation is one of the best methods, but one can note that few use it!

Conclusions from the study are that the most popular usability techniques are informal. They can be used quickly without much preparation. Formal usability evaluation with users is a highly ranked technique. HOwever, it is not commonly used.

What is Scrum and How is it Scrum Used?

I will kick off the fall by writing a series of blog posts on Scrum, Agile and User Centred design. This was one of my favourite research topics a few years ago, and I collaborated with excellent Marta Larusdottir from Reykjavik University in a studies around this.

Without doubt Scrum is the dominating systems development method in Sweden today. The name “Scrum”, is borrowed from Rugby where a Scrum formation is the one in the image of this blog post. The team is supposed to work tightly together as in this formation, one could guess :-). One can also guess that you are supposed to be male as a member of the team, as the majority of people who play rugby are male 😛

Scrum is really a very simple set of rules, as defined by for example Mike Cohn and presented in the image below:

Scrum .png

Scrum contains a whole set of roles and procedures too that you are recommended to follow, and of course these have unique and special names to make the concept more unique.

Many companies say that they use Scrum, or a Scrumish method. This could mean that they use one part of Scrum, or all of Scrum. We really did not know how organisations used Scrum, so we set up a study to find some answers.

In one of our studies Marta Larusdottir, Yuan Jia and I therefor tried to find out what parts of the Scrum method people use and hos usability is incorporated in the work. You find the below presented results in the following publication:

Yuan Jia, Marta Kristin Larusdottir and Åsa Cajander. (2012). The Usage of Usability Techniques in Scrum Projects. International Conference on Human-Centred Software Engineering, Toulouse, France.

We found out that the usage of the different fundamental activities and roles varied quite a lot. This is presented in the table below. A very large majority used sprint planning, whereas quite few used the burn-down charts. However, one can conclude that the percentage of people who said they used the different methods was generally quite high. There were no companies that claimed that they used Scrum, and then skipped large parts of the fundamental activites.

scrum activities .png



UX and Agile at the University of Pretoria

Last week I did a lecture at the University of Pretoria where I am visiting this week. There were about 45 students who were really active and interested. I started out the lecture by presenting myself, and then asked them what they knew about UX and Agile. They used Mentimeter when answering the questions, and the distribution revealed that they thought they had moderate to little knowledge. I hope that they know some more about the topic after the lecture 🙂

UX agile mentimeter

I presented some of the work that Marta Larusdotter and I have done and discussed some of the different ways UX work can be integrated in Agile.

We finished the seminar with a role play exercise where they got to dicsuss the different opionions one can meet when working with UX in Agile. When asked what they thought interesting about the excercise most of them said that it was interesting that all opinions about UX and Agile can have valid arguments, event though the opinion in itself is odd.

It was a very intelligent and promising group of students. And I really enjoyed meeting them!



Uppsala University Psychosocial Care Programme: U-CARE

Since not so long I am connected to “the Uppsala University Psychosocial Care Programme: U-CARE” as a member of an advisory group for the programme (programberedning). 

U-CARE is one of the Swedish government’s strategic research programmes and started in 2010. U-CARE studies how people with physical illnesses and their families are affected psychosocially, and what help they need to deal with various psychological problems. U-care are developing self-help programs for these disorders. They are also working to develop and continuously improve an Internet platform (U-CARE portal) through which it is possible to offer and study the effect of psychosocial support and psychological treatment.

You can find a very informing YouTube film about U-care here:

A few weeks ago Helena Grönqvist visited our department to present their work with U-care and the how the programme has developed. You can find the seminar at the seminar series on “Current Challenges in Biomed-IT”



In this seminar Helena Grönqvist talks about that they forgot to include the users in a structured way when developing the U-care platform and that they ran into problems due to this mistake. She also talked of the problems they encountered using Scrum and Agile.

(Not including the users is really a very common mistake, and I have written a few papers on user are included in Scrum projects (You find some of them here at Reserach Gate). Such a common mistake!)

They have now changed their way of developing the U-care portal so they now have a cyclical process where the users are included and a part of the development.

Some of the challenges that U-care face in the future, according to Helena Grönqvist, are:

  • New technology changes what users want. Do they need to have the portal avaliable on different platforms?
  • Legislation and for example the professors’ privelege is a problem since they want U-care knowledge to be open access.
  • Implementation problems: It takes 17 years until their innovation is implemented in health care. How can we make things move faster?

I am really looking forward to continuing this work and I will keep you updated on the work. 🙂

Seminar on Digital Work Environment with Examples from Health Care and DOME

Last week Gerolf Nauwerck and I did a presentation about Digital Work Environment at the Swedish Ergonomic Society’s yearly meeting. This blog post will shortly describe this presentation. It was the first time that Gerolf and I presented together, but despite limited time for preparing it went really well much thanks to Gerolf and an enthusiastic audience.

Gerolf started off the presentation by discussing the term Digital Work Environment that is used by for example Digitaliseringskommissionen, Prevent and Vision. For example Digitaliseringskommisionen defines it as:

 “The work environment in the digital economy”.

There is no scientific definition of the word, and in research other terms are used such as work engagement and healthy work.

Twenty years ago there were numerous different professions that worked with different tools, but working life has changed and today most work is done using a computer or an iPad, or other ICT technology, see image below:


When looking at the digital work environment there are numerous alarm reports from health care such as Isabella Scandurras “Disturbing or Facilitating“. Most health care professionals use around 25 different computer systems in their work, and these are often not connected or made to work well together even though they spend much of their time working through these systems. Physicians spend around 50% of their time working with the computer, and around 50% doing other things such as meeting patients. There are numerous media articles about the problems with ICT in health care, see the picture of the blog post. The problems are alarming, and health care professionals are as a consequence not always positive to changes related to IT.

One example of digitalisation in health care is medical records online for patients. Most physicians and nurses are very worried of the effects of this system. Mostly they are worried about the effects on the patient, but they are also worried about the effects on their work environment through the following changes:

  • Changes in well established work routines
  • Time pressure
  • Less time for preparation
  • Increased risk of misjudgements

Health care is not the only area where the digital work environment is problematic. Unionen (one of the largest Swedish unions) distribute a yearly or biannual survey to their members to investigate the digital work environment. The sub-titles of their reports called “The digital work environment of white-collar workers” tell us about the results from the survey:

2008: Why doesn’t it get better?

2010: A system error?

2011: Always online – never relaxed

2012: One step forward and two steps back

2014: No lightning ahead

In the seminar we continued with discussing what is known about software development and success factors, and we presented the results from the CHAOS report and research reports that show that one of the most important things when developing good IT for work is user involvement. But I guess that you already knew that 🙂


Working with Usability in Scrum Projects – what Usability Activities are Used in Practice?

A few years ago Yuan Jia worked with Marta Larusdottir and me as a master student doing her master thesis study in our research project on Agile development and UCD.

There was lack of studies describing to what extent different user centred methods were used in Scrum projects, so this became the topic of Yuan Jia’s master thesis, and which resulted in a conference paper. I remember that we had a very good collaboration with Yuan Jia, who now is a PhD student in the US.

When designing the study we quickly ran into problems with the number of respondents to our web based questionnaire. We did not have the mail contact information to people in organisation working with Scrum and user centred design. First we distributed the survey through the Uppsala Tax Office and LokaIdelen which is a website offering information to companies in Sweden. I also remember Yuan Jia’s long lists of company names and phone numbers as she systematically contacted company after company. Tedious work, but to be honest research work can be very much administration from time to time. In the end we had around 50 people who answered the survey 🙂

The survey has some interesting results, se Figure below. The most commonly used usability technique in Scrum projects is workshops, followed by lo-fi prototyping, interviews and meetings with users, all used by more than half of the participants.

One can note that all these usability techniques are informal, meaning that these techniques can be used quickly without much preparation. Formal usability evaluation with users is a highly ranked technique by the participants but not commonly used by them.




We presented the paper at the Human Centred Software Engineering Conference (HCSE) in 2012.

You find the paper here.