<p>Published on <a href="https://blog.prototypr.io/how-to-make-ux-and-agile-work-better-together-c4545978c39b?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Tony Smith <img alt="" src="https://cdn-images-1.medium.com/max/1024/1*20jlGKOCG4F97NQ6KUwaYQ.jpeg">Found on Pexels.com</p>
<p>As a UX Manager, I’m constantly looking for ways to make our process more efficient, effective and enjoyable. The good thing is there’s no one-size-fits-all process. But that also makes it hard to define for your particular situation. With that in mind, the our team at eharmony has made recent changes that can help inform the direction you take.</p>
<h3>Pain Points</h3>
<h4><strong>Competing Objectives</strong></h4>
<p>The main problem we encountered was aligning the design process with development cycles. Often the two have different objectives, timelines, and deliverables. The design team is trying to think beyond obvious solutions to give the business a competitive advantage. This requires timeframes that are hard to estimate. And, the output is sometimes more useful for further investigation or user testing than for production.</p>
<p>Engineers, on the other hand, have sprint commitments that need clear product requirements. Detailed specs improve the reliability of time estimates. For companies that feel the pressure to release code every sprint, the roadmap favors production work while neglecting innovation methods.</p>
<h4><strong>Dev Tools For a UX Process</strong></h4>
<p>Task management platforms, like JIRA, are used to track the effort and velocity of development work. Dev tickets are not the best place to include design concepts, user testing results or other UX output. They distract from the information needed to simply code and test a feature. Sprint planning meetings and tech sessions are also bad places to capture UX tasks.</p>
<p>So where does UX work fit in? How do we bring these distinct processes of design and development into alignment? Here are few options…</p>
<h3>Options</h3>
<h4><strong>Add UX tasks into dev tickets</strong></h4>
<p><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*9membCI670-AFN8y3Qj0Yg.jpeg"></p>
<p>One suggestion is to integrate UX work directly into sprint tickets. The goal is to account for these tasks and reflect the dependencies of dev tickets on design output (specs, prototypes, etc.). Developers have more visibility into the UX process and everyone is speaking the same language.</p>
<p><strong><em>Issues</em></strong></p>
<ul>
<li>UX work can effect multiple sprint teams</li>
<li>Scope of UX tickets are different from dev work</li>
<li>UX documentation can distract from information needed for production</li>
<li>Introduces new complexities for estimating and tracking work across multiple functions</li>
</ul>
<h4><strong>Completely separate tracking of UX work</strong></h4>
<p><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*FXvU1_nZ8txaZIkNDUEPZQ.jpeg"></p>
<p>Another solution is to remove UX from the sprint process altogether. Allow flexibility to find processes that work for your team and the particular project. Staying a few sprints ahead should allow for the unpredictable nature of ideation.</p>
<p><strong><em>Issues</em></strong></p>
<ul>
<li>Design teams using different metrics to track work requires a translation to dev metrics in order to align schedules and output</li>
<li>Increased likelihood of missed timelines when dev cycles are not followed</li>
<li>Potentially disconnects design from dev teams</li>
</ul>
<h4><strong>Use common tracking system in parallel</strong></h4>
<p><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*0r82pA3KCeea9tY9vPj6MA.jpeg"></p>
<p>The system we found to be most effective is to embrace the same task management system as tech teams (in our case JIRA). We work in sprints, estimate story points, and track velocity in the same way. However our tickets live on a dedicated UX sprint board. We define our own sprint stages that reflect our process (i.e. investigation, design, review, production, done). We also attach UX documentation to tickets without cluttering dev tickets. This is a useful way to reference concepts, rationale and key events in context.</p>
<h3><strong>Benefits</strong></h3>
<h4>Tracking and planning</h4>
<ul>
<li>visibility into effort, velocity and capacity allow for accurate sprint planning and resource allocation</li>
<li>limits of capacity force prioritization and alignment</li>
<li>tracking allows for diagnosis and optimization of the process</li>
<li>UX tickets can have different requirements than dev tickets</li>
</ul>
<h4>Documentation of UX deliverables</h4>
<ul>
<li>attaching concepts, rationale, research results, etc. doesn’t interfere with production information</li>
<li>content can be searched and referenced across teams within same system</li>
</ul>
<h4>Provides transparency to entire organization</h4>
<ul>
<li>all teams can view UX sprint board to see what features are on the way</li>
<li>allows time for feedback, adjustments and alignment before dev sprint starts</li>
<li>gives marketing, acquisition, and customer care lead time to support features/releases</li>
</ul>
<h3><strong>Recommendations</strong></h3>
<ul>
<li>Use same scoring format so product managers, developers, and designers are using common language (i.e. fibonacci sequence)</li>
<li>Just like dev teams, designers score tickets together and justify outliers to arrive at a more objective estimate</li>
<li>Allow designers to recommend the scope and structure of tickets. They know how they will approach the project, which tasks will be clustered and which are too big to complete within a sprint</li>
<li>Hold separate retrospectives with design, product management and tech leads to discuss previous sprint and optimize the next one</li>
</ul>
<p>Our projects typically run 1–2 sprints ahead of dev. We balance our sprints between smaller production tasks and larger ideation sessions. The production tasks keep a steady flow of deliverables going into development. But, these tickets don’t keep engineers busy for long. That’s why ideation is so critical. It produces a larger volume of projects and maintains focus on the strategic goals of the business.</p>
<p><img alt="" src="https://cdn-images-1.medium.com/max/1024/1*9ROauQ6T213pDJv1Y5GDgw.jpeg">Photo by <a href="https://unsplash.com/photos/3BK_DyRVf90?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">rawpixel.com</a> on <a href="https://unsplash.com/?utm_source=unsplash&amp;utm_medium=referral&amp;utm_content=creditCopyText">Unsplash</a></p>
<p>We found success by joining the Agile process rather than fighting it. That means tracking our process like tech teams. It brought us into the conversation about priority, scheduling and capacity. These topics used to be fuzzy assumptions that were hard to track. Now we have the tools to optimize our process and deliver high-value solutions.</p>
<h3><strong>Thoughts?</strong></h3>
<ul>
<li>What do you think about tracking design like a developer?</li>
<li>How do you track your UX process?</li>
</ul>
<p><img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=c4545978c39b" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou"></p>
<hr>
<p><a href="https://blog.prototypr.io/how-to-make-ux-and-agile-work-better-together-c4545978c39b">How to make UX and Agile work better together</a> was originally published in <a href="https://blog.prototypr.io">prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>


How to make UX and Agile work better together

Top Stories