Embedding UX within the Agile Scrum methodology.

The PRoblem

The need to establish a process for UX stemmed from my personal challenging experience working as a Product Designer adjacent to engineers who were part of Scrum Teams led by Product Owners. Essentially, I was not coping with last minute verbal requests for wireframes without being given concrete requirements or clear statement of the problem. Assuming this wasn’t just the case with me, I conducted some research to validate what’s was going on as well as collect perspectives of both Designers and Product Owners. I carried out a survey with 34 POs at the time, 21 of which responded, some with interviews. Other than that, I created and send a survey to 17 product designers as well as carried out group interviews. The following are the key findings;

Product Owners

• Lack time, context and resource to make effective decisions.

• Biggest concern is delivering the right thing.

• Need stronger partnership with UX Designers.

UX Designers

• Lack discovery time to define problem, while being pressured to produce design solutions.

• Are not doing enough user research.

• Are not fully utilizing their skill set.

The Process

After three iterations, the most recent process proved to be the most successful. This was because it addressed the majority UX Designers’ and Product Owners’ needs and challenges. More importantly, it empowered the team players in such a way that it established a healthy working relationship.

Here’s a summary of what was implemented;

• UX Designers were equipped with planning tools enabling them to estimate their work.

• A small tactical action in Jira allowed Product Owners to alert Designers of UX work needed.

• UX Designers managed their UX work in Jira by adding their task to relevant Epics and Stories.

• Design review sessions were planned throughout the life cycle of the project.

As a result of the above designers would not accept work unless it’s a ticket (task) in Jira and one that they were able to progress.

Measuring success

Following a number of roadshows, meetings and discussions, the process was accepted by Product Owners and Designers on various teams. Moving forward, I set a few objectives as follows and started to monitor adoption and success rates of the process;

1. Product Designers plan and share recommended UX tasks that is, activities, with POs.

2. All Product Designers UX work is tracked in JIRA against Epics and Stories.

3. All POs follow the tactical process of adding label to Epics and Stories that need UX.

4. Product Designers perform UX Acceptance Review of newly-developed user interface.

Monitoring adoption in JIRA

To understand how UX work was tracked and managed, I created a dashboard in JIRA. This allowed me to monitor;

• Number of UX Designer tasks being created, in progress, blocked and completed.

• Number of epics and stories labeled for UX work.

• Percentage of assigned tasks/subtasks per product.

Gauging User thoughts around the process

I needed some qualitative data to back up the quantitative data in Jira dashboard. I consistently checked in with the Designers to see how they were doing and overall it sounded good. However, I was curious to understand what the POs thought of the new process. So, after a month and a half of having evangelized and gained verbal acceptance from both Product and Project Management Leadership, I sent out a survey to all 31 POs.

The highlights of the results from a 50% response rate specifically, 16 out of 31 POs, was as following;

• 6 say they follow the process while, 8 say they do ‘sometimes’ and 2 say they do not.

• 5 find the process to be ‘good’ while 3 find it ‘somewhat good’ and only 1 finds it to be ‘not so good’.

• Only 4 POs said they have ‘full visibility’ of the UX Designer’s planning and ongoing tasks, while 9 said ‘partial visibility’ and the rest, 3 said they had ‘no visibility’.

• 12 POs say UX Acceptance Review is carried out while only 4 say it does not. The majority of those that carry it out 8, say that this is done ‘along the sprint as developer complete stories’ while 4 say ‘towards the end of the sprint’.

The following screens show the key results accompanied by reasons chosen and stated by respondents;

Conclusion & NExt Steps…

The Process had been widely adopted and has essentially, been considered helpful for POs.The following key observations are worth noting;

a) the higher the level of maturity and therefore, engagement and understanding between the two parties, the less reliance for labelling tickets for UX work,

b) while the lower the level or the less embedded the UX Designer is within a Scrum team or considered shared resource between multiple teams, the higher the need to rely on the process.

UX Acceptance Review is carried out by the majority who utilize different ways to raise or request the need for Reviews as well as methods on how these are carried. None are considered wrong, however, it is highly recommended that teams establish and formalize the procedure for when and how these Reviews are carried out, as part of their Agile Scrum Process or Project Chapter.

Lastly, the visibility of the ongoing and planned UX work is still poor. This could be counterbalanced by two initiatives;

a) on a daily basis, POs could use quick filters in their Jira project boards to surface tickets needing UX and all UX tasks the Designer created,

b) while at a project planning level, understanding activities which the Designer is proposing could be increased through evangelization of the UX Playbook and application of the UX Playsheet, (read the next story).