WRITINGS   |   ARTICLE BY: NICK ANDREOLI

Living in an Agile World: A Survival Guide for Working Onsite as an In-Sprint Designer  

Design as a practice is an ever-changing landscape with the need to constantly adjust our skills to deliver the most applicable and useful experience to our users and clients. Sometimes this means we have to dive deep into the trenches to work alongside the client and agile delivery team onsite.

This survival guide is meant to navigate you through the fundamentals of working on an agile team and to provide guidance on the challenges you may face as an onsite in-sprint designer. The ultimate hope is that your skin will come out thicker on the other side. 

1/ Understanding Agile Basics

How is a Team Structured?
While it varies based on organization and project, a full stack scrum team (aka pod) is comprised of individuals with different skill sets across different practices such as development (BE, FE, SA), design (UX) and quality assurance (QA). A product owner (PO), business architect (BA) and scrum master (SM) are also on the team to facilitate meetings and to keep everyone aligned with business requirements and decisions.
What is a User Story?
In the agile world, a user story captures a small piece of work in the grand scheme of a product build cycle, describing the type of user, what they want and why. Think of each user story as a pizza topping. They need to be cooked thoroughly and distributed amongst the different members of an agile team. But before you can layer on the toppings, you will need definition of the overarching business objective (crust), feature (sauce) and requirements (cheese).
What is a Sprint?
Let’s break it down so it’s digestible. A sprint — which generally lasts two weeks — is a chunk of time dedicated to completing any assigned user stories. These user stories are divided across all the sprints. The pizza is then cut into individual pizza slices, each slide representing a sprint. 

2/ Write Meaningful UX Stories

In grooming and sprint planning sessions, you will work directly with your team to determine business requirements, immediate needs and complexity from a UX perspective. The product owner and/or business architect on your team should own the stories, ensuring all criteria is captured.
Types of UX Stories
IN-SPRINT
Fairly immediate UX work needed for development consumption within a few sprints. (e.g. Your print online service needs an area where customers can enter in special instructions for their print order.).
NON-FUNCTIONAL
Concept work that could eventually become in-sprint UX stories. (e.g. You are undergoing a user validation session soon and need to allot time for preparation: research, protocol creation and workflow diagrams)
EXAMPLE USER STORY
UX Story Criteria: Acceptance Criteria (AC’s)
Each story should have a list of AC’s which explain overall behavior, functionality, requirements, error scenarios and any other data/obstacles that could affect your work. Before a story is closed out, the PO/BA/UX should review together to ensure the AC’s pass. 
EXAMPLES OF AC's:
  • User needs to be able to type instructions so team members can process an order that contains print options not configurable in the system.
  • When print instructions exist, the price of the project cannot be calculated.
  • User should be able to edit, remove or save their print instructions.
UX Story Criteria: Tasks
Each story should have a list of tasks, each acting as a touchpoint, reminder or action. Having a task list will also help with assigning point values to your story.
EXAMPLES OF TASKS:
  • Finalize copy and integrate any error or other edge use cases.
  • Export, link, hotspot all screens to InVision prototype.
  • Present designs to stakeholders in design review.
Assigning Points to Stories
A point structure is used when defining stories and are assigned based on level of effort and estimated hours for completion. Because a huge chunk of your time will likely be consumed with in-sprint ceremonies (covered later in the article), you should only account for 6 hours/day for actual design time.

3/ Design Iteration & Reviews

Design Individually or Collaboratively
Once you have all the business requirements and ACs for your stories, you can begin on any design work needed. Build out any user flows and include components such as: hover states, error screens, special messaging, additional breakpoints and any desired interactivity or functionality. Stakeholders love to see multiple options/ideas, so consider this if time permits.

Make sure to review your ideas with developers, so they can predict the level of complexity to build or integrate with the system.
Review Internally with Design Team
It is integral to give — and take — feedback from other designers and leads on the project. Not only will it keep your skills sharp, but will ensure design system and cross-pod alignment, putting you in a better spot when presenting to stakeholders and preparing for development handoff.
Review Externally with Client Stakeholders
Schedule formal design reviews towards the end (but not AT the end) of each sprint to allow for adequate design and revision time. Designers should lead these meetings and always include necessary stakeholders, your product owner (to answer business-related questions) and a lead developer (to address any technical concerns). 
Keep the meetings on track by setting an agenda and let attendees know that feedback should come at the end. 

4/ Create Solid Documentation for Developers

When flushing out final documentation, be as descriptive as possible to ensure it can be understood by a developer without any context. (You never know who is going to pick up the work!)
  • Create extensive documentation using final designs and different breakpoints.
  • Include any components needed to complete the build.
  • Incorporate purposeful annotations and arrows to show screen flow.
  • Export to a dev handoff platform such as Zeplin so it’s easily accessible, commentable and versionable.

  • Keep communication lines open by sprinkling kickoff, check ins and final desk checks throughout each sprint.

5/ Stay Organized

You will rarely be the sole designer on a project. Resources may get swapped out or another designer on your team may help out with your workload. That said, it is imperative to ensure your work can be easily discovered and understood by anyone other than yourself. Make sure stories/features are well-organized across each application you are using, whether that is JIRA, Sketch, Figma, InVision, Zeplin, Abstract or another production tool.

6/ Manage Your Time

Since sprints generally last only two weeks, it is important to use your time efficiently, factoring in team ceremonies as you allot time for design work.
  • Team Standups
  • Design Syncs
  • Story Kickoffs
  • Desk Checks 
  • User Story Grooming
  • Retros
  • Demos
  • Design Reviews
  • Sprint Planning
Multiple studies confirm that distractions don’t just eat up time during the distraction, they derail your mental progress for up to a half hour afterward. Block off time each day — bonus points if you can have one no meeting day once a week — on your calendar to be heads down with design work. This means that sometimes you need to push back unnecessary, irrelevant and duplicative meetings, or delegate to someone else.

7/ Reality Check

While being an in-sprint designer can certainly be difficult, it is the necessary reality of what we do for enterprise businesses. Here are some tips to help overcome common issues that may arise:

Daily work can sometimes seem monotonous and draining, with limited time for creative exploration, personal growth and cultural rejuvenation.
Allocate time each sprint for concept work and/or self-exploration. Take a breather and get inspired. Re-energize with a sunny beach vacation or some meditation. Embrace your fellow onsite colleagues for support, feedback and to meet offsite regularly for coffee, lunch, happy hours and therapy sessions.

So many rules about writing stories and setting requirements. So many meetings! Constant hounding to deliver each sprint!
Welcome to the world of agile. Our clients have clients as well who rely on the software/experiences we are building. Sometimes we will feel the pressure of that. Learn to accept we are making a difference and that there are a lot of pieces involved in that process.

UX can get deprioritized and/or forgotten about.
Sometimes clients prioritize development work — the quicker the launch of a product or feature is, the quicker the customer and top leaders in the organization are happy. Take initiative to educate your client on the importance of UX/design — the way something looks and works should always be methodical, never an afterthought.

Skill level gap between in-house and consultant talent.
Be a teacher, be a mentor...help them improve in their craft. Facilitate or advocate for training programs to allow them to succeed.

Internet, site access and onsite accommodations are not always optimal.
If possible, make arrangements to work elsewhere from time to time, especially if it affects your ability to do your best and most efficient work. You should be comfortable in your work setting, as it is your second home after all.