Many UX professionals working in Agile environments feel frustrated, overworked, and ineffective in meeting both business and user goals. The rapid, timeboxed pace of Agile is the main reasons for these negative feelings.

Agile is not easy for UX. When pressured to tackle a mountain of design requests, and saying “no” is not an option, managers often spread UX talent thinly across numerous teams and projects.

Successful Agile development requires full participation and dedicated involvement from the whole team, including UX designers. But UX designers who work on multiple distinct Agile projects, are highly likely to fail. When cranking out prototypes is a means for survival, thoughtful design solutions and UX best practices are often laid by the wayside. As a result, not only do the final products suffer, but UX professionals burn out and become dissatisfied.

Managers who track the capacity of the UX team (i.e., the maximum amount of work achievable within a given time period) can be more effective in allocating UX resources. Armed with a capacity value and accurate work estimates, managers can make good decisions and engage in productive conversations with stakeholders about what their teams are able to realistically take on, and how to best prioritize the requests.

Estimating UX Work Apart from Development

A foundational practice in the Agile development process is to estimate work by assigning story points to each user story or feature. Traditional Scrum teams usually choose a single estimate to represent the level of effort shared among team members, regardless of disciplines. This practice sounds good in theory.

However, in many cases, a single estimate for user stories does not represent UX effort well. UX effort can be significantly disconnected from development effort. Take, for example, an undo feature. For UX, it could be a quick button design, but for developers, ensuring that the correct data is returned might require much more effort.

Having different work estimates, one for UX and one for implementation, is more realistic in some cases and allow teams to plan their work appropriately.

A major downside to having two different effort estimates is that it may require more coordination between UX and development, but it does not automatically mean that team members are out of sync. With thoughtful communication, especially between product managers, development, and the UX group, team members can work towards the same goals while using their talents more effectively.

For many teams, especially those who build complex systems, separating the UX and delivery work streams is a common practice. (In fact, dual-track Agile projects have been the best practice for a decade.) This divide-and-conquer approach can increase efficiency by allowing members from each discipline to contribute adequate time to address the current feature. If, in your organization, UX work and delivery work are mainly conducted in parallel streams, it’s advantageous for both groups to separately estimate the effort needed for each type of work.

However if your Scrum teams assign a single number to represent team effort for each user story, then it’s perfectly fine to continue this practice for UX work. In fact, it is ideal because the risk of communication breakdown is reduced.

Calculating UX Velocity

When estimating work, UX groups often borrow scales commonly used by development teams. For example, different UX user stories may have estimates of 1, 2, 3, 5, 8, 13, 21 story points. These values represent the relative size of UX user stories. For example, an item estimated as needing 8 story points requires 4 times more work than an item estimated as needing 2.

Let’s say that your UX team’s capacity is 50 story points for one iteration. Based on this value, you can determine how many UX stories your team can commit to. In this example, if a design requires 21 story points, you’ve spent almost half your design budget on that feature, so it better be worth it.

It doesn’t matter which scale you use, as long as you are consistent and can effectively communicate what it means to others outside your team.

If you haven’t estimated before, it can feel daunting. You might fear that your estimates might be inaccurate. Don’t give up. Most UX teams discover that it takes several attempts before estimates become precise. And with time, the estimates do get better. It’s important to know how your UX-team capacity evolves over time. As team members gain experience and strengthen work processes, they may be able to do more.

Advantages of Establishing Capacity Limits

Negotiate UX Commitments

Knowing your team’s capacity is a useful communication tool to negotiate what you can commit to. It removes any notion of perceived subjectivity in your arguments for what you can and cannot work on.

Rather than simply saying, “I can’t do it,” work estimates can make a compelling case for why accepting a request, regardless of size, requires some level of renegotiation. Estimation removes the emotional element often attached to turning down or postponing requests.

If you have a concrete number to represent capacity, you can point to it as a reason for why a feature might need to wait or be reprioritized. The UX capacity can also be useful in communicating with human resources when requesting more staff.

Show Transparency

When UX effort isn’t appropriately represented, UX work becomes less valued. Tracking UX capacity makes UX effort appear less nebulous to outsiders. So when they ask you to do just one more small thing, they can see why you might need to push back.

Keep Your Top Talent

A lack of estimates can lead to poor resource planning, causing UX professionals to feel overworked and disillusioned. When estimates are nonexistent, it’s difficult to say no, or push back on work. As a result, many UX members feel pressured to overcommit to projects, which results in the overall impact of UX being severely compromised.

Without measuring capacity or understanding the effort needed for a project, requiring UX designers to work on multiple teams at once dooms UX for failure. Too many organizations have lost top UX people by setting them up to fail. Better to place UX effort in key projects where UX focus will significantly affect release goals than to spread it thinly across many initiatives where results are less than ideal.

If you need to hire more UX professionals, point to capacity estimates as a reason for your request.

Review Past Estimates

After you have followed our recommendation to estimate UX story points for several months, you should double back and compare past estimates with the actual resources spent on those activities you completed. Most likely, the estimates were a bit off. Estimates always are, and you can be sure that the development estimates aren’t 100% accurate either. No shame in not hitting the bullseye with every estimate.

But in those cases where your estimates were far from the reality, you should try to find out why. What early warning signs should have caused you to increase a certain estimate? Or what issues seemed burdensome before you initiated the work, but turned out to be overcome quickly?

Sometimes individual idiosyncrasies cause an estimate to be wrong. But other times there are systematic issues you can identify that cause estimates to be consistently wrong under specific circumstances. Discovering such conditions can make your future estimates more accurate and thus improve the management of your UX-resource allocation.

Conclusion

Keeping separate UX user stories is not a requirement for UX success. If you already have strong communication among team members (and management), tracking UX effort is not critical. However, if managing UX work feels haphazard, UX user stories can work in your favor. 

Agile relies on estimates to communicate velocity. Having UX estimates allows you to communicate using terms that other Agile members understand and relate to, thus making it more effective for you to negotiate UX commitments.

Get more tips on how to approach UX in Agile environments in our Lean UX and Agile seminar, our Effective Agile UX Product Development report.