Carlos Tay, a Works Community member and UX researcher, has shared how UX design can play a vital role in aiding agile teams in achieving success in his blog post for the Writer’s Room.
To promote open communication, encourage innovative ideas, and ensure successful product development, it is imperative for UX designers and other team members to proactively attend scrums and other important meetings.
Transitioning from traditional product development processes, like Waterfall, to modern Agile frameworks, like Scrum, can be a daunting task for UX designers. However, when successfully implemented, Agile is more than just working in short, time-constrained sprints. In a UX-driven environment, it is important to avoid newly-coined jargon or jargon-free terms when collaborating on multi-disciplined projects, as it can be challenging to keep the user’s needs in focus.
The Scrum framework is different from Waterfall due to its ceremonial meetings, including daily stand-ups, sprint planning, backlog refinement, retrospectives, and demonstrations. For UX technologists transitioning to Agile, participation in these meetings and understanding how to make the best use of their time can be a challenging task. This essay aims to delve into the role and responsibilities of a UX technologist in each Scrum ceremony, highlighting how they can effectively communicate, influence product development, and make valuable contributions to the team. Although the essay focuses on Scrum, the principles discussed can be implemented in other Agile frameworks as well.
UX Must be Included in Events that Require Ceremonies
Being a UX designer in an Agile team demands more than just planning sprints in advance to share ideas with the product owner, stakeholders, and developers. It is expected that you actively participate in all the rituals and meetings associated with the ongoing sprint – overlooking or avoiding Scrum ceremonies is not a viable option.
Neglecting or not fully participating in ceremonies can be precarious as it increases the likelihood of forgetting:
- The perspective, goals, and objectives for our product
- Users of our product need not worry about the aforementioned issues anymore
- Our team has a collective sense of purpose.
- The feasibility and implementability of development
- How our design specifications are implemented by programmers
- The upcoming sprints and where to focus, as well as the reasons behind it
- Instances where an additional research or sprint 0 time is necessary,
- Scenarios where user-centred evidence may contradict a design based on assumptions
- Encourage the team to observe research or participate in seminars.
- Instances where improved UX can make a significant impact
- Anecdotes of users requesting additional information from UX designers.
- Situations where we may need to offer assistance with testing for quality assurance purposes
Skipping ceremonies can have a negative impact on team relationships and communication. It’s crucial to avoid this by addressing any possible oversights and maintaining a positive attitude during ceremonies. Keep in mind that some team members may not have the time to catch you up on things.
If you’re having difficulty managing your workload within the given time constraints, it’s crucial to reassess your tasks to ensure that developers have the necessary resources for the upcoming sprint. This will allow you to make time for ceremonies. As you progress, you may be able to establish a more efficient system of task allocation that will permit you to reintroduce activities that were initially removed from the sprint agenda. In an agile environment, it’s important to monitor your workload to prevent burnout and guarantee that you don’t overlook any crucial events.
If you’re still struggling to attend ceremonies, it’s advisable to discuss with your manager, product owner, and Scrum master how you can effectively manage your workload and participate in ceremonies. It’s essential to have team members advocating for your presence and contributions. If they aren’t already aware, explain why it’s crucial to include UX as the customer’s voice in Scrum ceremonies to prevent the accumulation of UX debt. Without customer input, the team may have to discard, reassess or reconfigure elements that were not initially designed with the end user in mind.
What if you aren’t dedicated to a particular product team?
If the UX team is accountable for only one product team, attending all ceremonies is relatively manageable. However, if they’re responsible for several development teams, it may be difficult to attend every ceremony. In such cases, it’s advised to prioritize attending ceremonies during the transition from discovery to delivery phase, even if it’s not feasible to attend every ceremony.
Participating in a ceremony is not just a matter of attendance, but also an opportunity to make an active contribution. Make sure that your presence is valuable by sharing fresh insights from your research or collaborating with developers on user stories. If you’re unable to attend due to a conflicting meeting or other pressing obligations, your product owner or Scrum master will update you on the meeting’s content.
If two meetings are scheduled on the same day – such as a morning daily standup and an afternoon sprint planning session for a team in the midst of delivering a crucial release – the sprint planning meeting should take precedence. Following that, it’s recommended to speak with the Product Owner or Scrum Master to identify any issues where UX can provide assistance. During instances when UX must divide their attention, it’s acceptable to rely on colleagues to keep them informed and involved as much as possible.
Determining priorities when faced with competing demands and limited resources
Determine which events are not required for UX and exclude them if time or resources make it impossible to attend all of them. The following five questions can help prioritize direct conflicts with Scrum ceremonies and manage the fact that it may not always be feasible to attend all team meetings.
Will my absence from the ceremony hinder the development team’s ability to achieve the sprint objective? If yes, it’s advisable to attend the ceremony. If not, it’s acceptable to prioritize other tasks.
Do I need to communicate any critical information about our product and user experience to the team during the ceremony? If so, it’s recommended to attend. Otherwise, you can redirect your attention to other tasks.
Is there someone else I can discuss with after the ceremony and get an update on what happened from UX’s standpoint? If the answer is yes, you can focus on other tasks. Nevertheless, if feasible, try to attend the event in question.
Have I spent ample time collaborating with developers to feel confident that they understand the essence of my designs and the insights obtained through user testing? If yes, you can devote your attention to other tasks. If you don’t mind skipping the ceremony, you may do so.
Can I confirm that I’ve attended at least three ceremonies in the last two sprints? If yes, it’s recommended to attend the event in question. Otherwise, you can channel your attention towards other tasks.
When UX resources are too scarce, this decision tree can be utilized to determine whether or not to participate in a Scrum ceremony.
Optimal UX Strategies for the Daily Scrum Meeting
Daily Scrum (Standup)
Typically, Scrum teams hold a brief daily meeting referred to as a “daily Scrum” or “standup.” This meeting, included in the Agile framework, should not exceed 15 minutes and is intended to guarantee that the team is making progress on their tasks and promptly addressing any issues. To provide succinct responses to the queries, all team members, including those from UX, remain standing throughout the meeting.
- Describe your previous day.
- Illustrate the sections of the layout for which you were accountable.
- Elaborate on any collaborative efforts with partners from other departments.
- Explain the methodology you employed, the outcomes you achieved, and any inferences you made from your research.
- Communicate any research or user insights, even the most fundamental, to the team when relevant.
- To put it differently, how do you intend to allocate your time today?
- Disclose your everyday schedule for design, user research, design critiques, workshops, and design sprints with your team.
- You can ask for assistance from engineering and product departments.
- Coordinate group endeavors using structured whiteboarding or drawing sessions.
- It is advisable to include team members in the usability testing and any other research that will occur that day.
- Stay focused on your task by announcing, committing, and verifying with your team that you will accomplish the job.
- Precisely, what is hindering you?
- Explain the internal and external barriers preventing you from accomplishing your task.
- Utilize your Scrum master as a resource to resolve these obstacles.
Following the standup, suggest a quick follow-up meeting if you need to discuss specific matters with team members.
Sustaining team unity can be difficult, particularly when the UX team is several sprints ahead of the engineering team. Therefore, it is crucial for UX members to attend daily standup meetings and offer brief, well-defined updates on their advancement. In standup, UX experts should also be aware and make note of any possible barriers or problems which UX may be able to aid with.
Enhancing the Product Backlog
Halfway through the ongoing sprint is usually when the product backlog is refined, also called backlog grooming. This practice aims to prepare the backlog for the following sprint planning session (and subsequently, the sprint). The product owner will reassess the priorities of the backlog items to ensure they conform to the company’s demands and end-users’ needs. To decide whether new stories are necessary or if existing ones require modification or elimination, the product owner will facilitate a team discussion. The team may revise or expand on existing stories to address all aspects. By incorporating ideation techniques like whiteboard drawing, the team can solve problems more effectively, particularly when UX specialists are present to provide support. ‘Spikes’ can be assigned to backlog items that require further research in the current sprint to resolve uncertainties and provide answers.
Items in the backlog should only be deemed ready for a sprint when they have sufficient information and background according to your team’s criteria. This guideline avoids accepting sprint tickets without context, preventing the squandering of time that could have been used in determining the actual work that needs to be done. Each team has its process of defining when a backlog item is finished. However, if the final outcome is to be showcased to the users, it must meet the user experience (UX) requirements specified.
- The ticket contains an elaborate explanation of the issue and the criteria to be fulfilled.
- There are pictures and limited documentation to review.
- The solution has undergone user-testing, and so far, no significant issues have arisen.
- Design adheres to a predetermined set of rules stated in a manual or pattern collection.
- UX, development, and the product owner have all reviewed the item.
During backlog grooming, a UX Designer’s contribution can be valuable to the development team in planning for the next sprint, providing additional support to the Product Owner. Although Product Owners should understand user requirements and business objectives, they may have a lot to handle, such as reconciling the needs of the engineering team, organizational strategic goals, and core performance metrics. When prioritizing tasks, UX Designers should steer Product Owners towards the optimal solutions for users and the product.
Planning in Brief Intervals
Before commencing a sprint, a sprint planning session is conducted to evaluate the prioritized backlog items and determine a practical estimate for their completion. The product owner will steer the discussion and ask the team for their genuine opinions on each item. This leads to the formation of a sprint backlog based on the team’s velocity (i.e., the amount of work they are willing to take on). Additionally, an attainable sprint objective – a brief statement of what the team aims to accomplish – will be established, which serves as the sprint’s focus.
UX tasks should be integrated into the backlog as either standalone tickets associated with Engineering’s Epics, or as subtasks connected to the main user story. Rather than relying on narrative points, using t-shirt sizes is encouraged for estimating UX work. If the Scrum team predominantly employs velocity for engineering tasks, the same method should be followed for assessing UX stories.
Using t-shirt sizes instead of narrative points to evaluate the UX workload for a product is an excellent method to avoid slowing down the engineering team’s progress. A product that necessitates a significant amount of UX work (size L) will require more effort, whereas a size S product will necessitate fewer resources and might utilize all of the UX resources throughout the sprint. To avoid delays during future sprints, the development team can keep track of the workload and ensure that UX isn’t overburdened in the current sprint.
To avoid the neglect of vital research and design tasks, it is crucial to make UX work accessible to the entire development team via a ticketing system. Including the team in sprint planning is an effective approach to keep them abreast of the UX work that will occur throughout the sprint. This will foster comprehension and support for new techniques and proposed changes, potentially leading engineering and product team-members to understand the thought and work behind the design and research process.
To ensure that everyone on the team is informed of the process and able to participate, it is crucial to include user testing sessions and debriefs in your sprints. We suggest slightly reducing the sprint velocity to allow for more extensive research initiatives or workshops such as design sprints, which require the team’s full attendance. This will enable engineers to attend research sessions without the need to multitask or compromise the sprint goal.
Participant recruitment is a crucial aspect of your role and should be factored into your planning. To ensure a smooth and efficient process, it is crucial to have a systematic approach to user recruitment. This can save time and simplify the research process. Moreover, it is critical to keep a list of potential participants and regularly update it. To increase the number of individuals willing to participate in your study, you may explore options like advertising, hiring market researchers, distributing flyers, or adding more questions to your forms and surveys.
Once Sprint Planning is completed, the team should have a clear understanding of the amount of work that must be accomplished during the Sprint. It’s important to note that the User Stories discussed during Sprint Planning are only the starting points of the conversation, and that additional dialogue and collaboration will be necessary. It’s advisable to stay in touch with the team throughout the Sprint and be accessible for questions or discussions, rather than simply attaching designs to User Stories and expecting the best.
Evaluation of the Briefest Possible Time (Demo)
Typically, at the end of a sprint, a review – also referred to as a ‘demo’ – is conducted. If the team is concluding the sprint, the ceremony typically takes place the day before the code is released. The product owner will present any stakeholders or potential customers who may be affected by the outcomes of the sprint with an overview of the team’s progress in terms of functioning code. UX can aid the product owner in demonstrating progress during the sprint review by summarizing the work accomplished during the sprint. Additionally, they can discuss test findings and user-centered insights that have influenced the current release or will benefit future product versions, making it a mutually beneficial situation.
A UX designer may feel overwhelmed when faced with a significant number of feature requests or feedback during a sprint demo. To address this, it’s important to categorize comments into groups such as ‘to-do,’ ‘clarify,’ and ‘persuade,’ and work with the product owner and scrum master to prioritize the new requirements. To avoid any surprises or unrealistic expectations, it may be necessary to regularly involve cross-functional partners at an early stage in the sprint.
Retrospective
To accurately evaluate the outcomes of the sprint, the team should conduct a retrospective on the day following its conclusion. To ensure impartiality, it’s preferable to have a third-party like a Scrum Master from another team or a Project Manager from a different department facilitate the session. All members of the Scrum team should be encouraged to express their opinions on the successes, challenges, and opportunities for improvement during the sprint.
During the retrospective, it is recommended that UX proposes process improvements. Everyone will be in a reflective mindset and willing to hear about ways to enhance their work. In a workplace that prioritizes developers, it may be challenging to advocate for process improvements that would promote better UX work, making it advisable to present ideas as experiments to be tested in the upcoming sprint.
Conversations regarding:
Instances where resources or time were insufficient for thorough research required for quality design.
Final code diverged from original concepts due to inaccurate or insufficient communication between UX and developers.
Doubts concerning the outcomes promised and the design completion criteria proffered.
Unclear or insufficiently detailed methods of conveying design requirements causing issues.
Usability testing participation from product, technical, and business stakeholders.
Listening to ways to improve team communication and sharing your ideas on why the previous sprint could have been more successful is critical. Are the design requirements clear? Have you provided your team with user data that is irrelevant to the current sprint? Is it difficult for you to apply your designs within the existing architecture or frameworks? Furthermore, it’s vital to assess whether or not you’re supporting the rest of the team in overcoming any obstacles they confront; only then will UX be seen as a valuable asset.
In retrospectives, it’s useful to examine whether any of the recently completed user stories entail UX debt or compromises from a user-experience viewpoint. Sometimes, choices must be made that may result in deprioritizing the user experience in order to complete the work during a sprint.
Regular retrospectives are crucial for maximizing the benefits of an Agile methodology. The team must decide on the most effective approach, but the true advantages of the methodology can only be realized after testing it and identifying what doesn’t work. Since Agile teams typically conduct retrospectives, UX-related ideas are likely to be implemented. However, it’s critical for the team to take the time to comprehend the consequences of any changes before acting hastily.
Interested in becoming a part of the Works family? Join the Works Talent Network!
Works is devoted to forming remote engineering teams that are reflective of the world’s population. Our community consists of over 175,000 professionals from more than 90 countries. Members enjoy various opportunities to participate in events, receive perks, form partnerships, and attend both virtual and in-person gatherings, providing them with opportunities to connect with like-minded individuals and expand their horizons.
To join the Works Talent Network, simply follow the on-screen instructions on the Works website.
To submit an application, kindly complete our online form.
Allocate the next 15 minutes to take an English proficiency test.
Achieve a passing score on a technical test assessing your competency in the language(s) of your preference (Python, Golang, etc.) – 1 hour.
Arrange a one-hour technical interview with one of our Senior Developers.
Visit the Works Talent Network registration page for more information.
If you found this article helpful, be sure to check out our other posts for related content.
