SCRUM FOR Strategists, UX and UI DESIGNERS ON A TECH CENTRIC TEAM
Scrum can be challenging for designers. It endeavors to minimize design debt, and so the scrum process may not allow designers to work ahead—but there is a way to work with this by adding a few things to the mix.
I've found that most tech teams do care about a good user experience, and love to be included in discussions on how to make it better—they just don't always know how to go about it. Your design skills are an asset and it's up to you to become a guide in giving your team the tools to become UX advocates.
Personas—Guide your team in creating a fictional or proto-persona. By making it a group effort, everyone will know who this is for. It sets the team up for creating the user journey.
User Journey—Collectively create a user journey on the wall in sticky notes. This will become the backbone of your product and features. Always guide the discussion in favor of a good experience for the end user. This is important because actual features will be written out later based on this user journey.
User Stories—Once the persona and journey is in place, it's time to write user stories to populate the backlog. Don't let your team get too lost in tech jargon while writing user stories. It's OK for the team to discuss the technical aspects in depth before writing the actual user story. When it's time to put ink on the notecard and things get off track, gently ask, "How does this support [persona name]? Let's bring the story back to how this benefits our user."
Occasionally, there may be sprints where we need to clean up technical or design debt and we write stories that start like this: "As an API engineer,..." or, "As a UX Designer..." We want to avoid this if we can. Technical or design debt happens, but hopefully it only occurs minimally. In general, make sure your team fills the backlog with stories that are for the end user.
Once the stories are written—they become your workload for the sprints ahead. So make sure your UX input has helped to hone each story with the end user in mind.
MINIMIZE THE WATERFALL
For designers, it's a challenge to start a sprint with others asking, "What are you going to design for this screen? Can I get a look at that soon because we need to start building this sprint."
If you haven't already researched, investigated or sketched—you're faced with an impossible situation: A user story doesn't mean you have any clue on how it will work or look. And yet, your team needs you to deliver right now.
This is complicated. Designers need a little time to work ahead. However, creating documentation where the rest of the team has been excluded, is a bad idea. Refined documents can separate the group and the process is no longer agile. How do we overcome this?
BUILD IN WHITE BOARDING SESSIONS As Part of Scrum and Have the Promised CONVERSATION
In scrum, we have sprint planning and grooming sessions. We write user stories on notecards as a promise to have a future conversation. We hand-write these stories on a small card for a reason—to constrain the size and avoid heavy documentation or waterfalls and share it with the team by talking together and sharing insight. How can we incorporate this principle of agility, brevity and inclusivity as part of the design process?
The UX/UI discovery phase often involves sketching on the dry-erase board. If we do it as a group and formalize this as a part of the scrum process, we are furthering the conversation together, while keeping the designs light-weight and agile.
Identify Next Sprint User Stories—Work with your product owner to collectively identify user stories in the backlog that are prescient and are likely to be in upcoming sprints—preferably next sprint. (This requires having had grooming sessions and a decent number of user stories with acceptance criteria ready in the backlog).
Agile UX Sketch Sessions— 1) Coordinate with the scrum master to allot time for ux/ui sketch sessions. Make sure this session is at a separate time from grooming so that your team is fresh. 2) Gather the whole team and discuss the stories your product owner has selected for ux/ui sketching. 3) Lead a brainstorm session with your team; Do some research before and be the first to sketch some ideas as a point of departure to get the session going. Sketch with the dry-erase board and come up with user flows and UI solutions together. 4) Make sure to encourage a person from each discipline to get up and share ideas on the board.
The Light of Design—A picture is worth a thousand words. In the beginning, a sketch can spur questions or disagreements amongst the group—and this is a good thing. You WANT to expose these areas. It forces each discipline to contribute to the solution. The disagreements without-end may be indicative of a user story that's too big and may need to be resized or broken down into smaller user stories. Either way, it's healthy to hash things out and get on the same page with your team.
If there is no consensus, then plan another session. The design process is a tool to expose areas where there may still be confusion, and it avails an opportunity to deepen the conversation.
Create and Share a UX Channel—At the end of the session, take a picture of the flows, sketches, ideas and post them on a wiki. I created a channel on Slack for UX Design. It's a great way to share content and exchange ideas with your team during sprints. If your team has not chosen a communication channel, then ask your scrum master to help establish one—it's essential for a scrum team to communicate during active sprints. Write a bullet-point list of your takeaways from the session and post it. As you progress in the design process, share on this channel. Post frequently so that your group can provide feedback, and you work iteratively with the team.
Sketching ideas and brainstorming with your team creates the necessary overlap and transparency between disciplines to keep the sprint and design process agile. It also grants time to consider the user experience a few sprints ahead, without creating a waterfall workflow, while mitigating heavy documentation.
SPRINT PLANNING AND USER TESTING
What would a scrum team be without user testing? Imagine a car heading down the road at 100mph without a steering wheel. You'd be off the road before you know it. A scrum team that doesn't test its product along the way would be like driving a car with your eyes closed. Frequent testing can identify pain points early on for your team. Test your product often, as early as possible, with whatever means necessary. Document and share test results with your team on your UX channel, then write new user stories to address the pain points.
Plan Ahead—Make sure you write user stories that incorporate user testing into the backlog: "As a UX Designer, I need to user test "X", so that I can identify pain points, to ensure that [name of persona] has a better user experience".
Reduce Technical Debt—Sometimes testing will reveal which features actually get used. By testing sooner, you ultimately reduce technical debt by focusing your teams efforts only on features that are truly needed.
Be Inclusive—If possible, invite your scrum team to observe user testing. This reinforces their role as UX advocates and raises awareness as well as consensus when it comes time to write new user stories during grooming sessions.
Test Script Targets—If your team is several sprints in, and there are areas in the user experience you know require attention that the team is neglecting, try writing a test script to target those specific areas, and see how candidates interact. User test results are very powerful—and are a way to get the product owner or stakeholder's attention to address the issues. If the drop-off is big enough, then the user stories addressing those pain points usually command a higher priority within the backlog.
New User Stories—Write user stories derived from pain points. Share testing documentation with the team, and introduce them into the grooming sessions for backlog as soon as possible.
CONCLUSION
If you embrace team inclusivity and introduce these design principles to the scrum process, it can be a great working model for designers. Guide the team in design and inspire them with the said tools so that they can become UX advocates. Avoid design debt by furthering the conversation with sketch sessions. Keep the documentation light-weight for agile development on a channel so that the team can observe and share feedback as you iterate. User test your product frequently. Instigate team focus on the features that support and delight the user by leveraging user testing documentation to win the product owner's attention.