In UX Leadership, cross-functional collaboration is more critical than ever. Orchestrating UX research and design usually requires some level of Time estimation necessary for communication across teams.

Over the years, I have noticed how typical UX Deliverables such as user research, persona creation, journey mapping, wireframes, and prototypes are required for almost all projects.

Often, UX Teams are asked by our Scrum Masters, Product Managers, and Project Managers to estimate the Time it will take to complete these deliverables. It’s their job to factor UX estimations into a much larger schedule or roadmap. I have also come to find that estimating only in Time is absurdly inaccurate.

While experimenting at UX and Agile's intersection, I have found success with Relative Sizing for estimating UX. This article will share how Relative Sizing (an Agile method) can help your UX team become more accurate and predictable in estimation efforts.

It will enable more effective collaboration between the team and UX, with the added benefit of your cross-functional partners loving you all the more for it.

As a side note, this method has been successful for me in the past, and I would like to share this strategy with this community; however, there may be situations where this methodology will not work or may need to be modified. Take away what you will, and, as always, use responsibly.

What exactly is Relative Sizing?

First, it’s essential to understand a little history of Relative Sizing. Relative Sizing is rooted in Agile and provides a different perspective on estimation.

It opposes the prevalent yet massively inaccurate measure of Time. Relative Sizing took the Time variable entirely out of the equation (Maximini). During my pursuit of advanced Agile knowledge, I learned from the Brad Pitt of Scrum Trainers, V. Lee Henson; CEO, and President of Agile Dad. Lee provided a perfect analogy; think about shoes. What Size is your shoe? Let’s say it’s an 8.

Let me guess it took 8 hours to make, or 16 hours because there are 2 of them? Silly, right? 8 is simply a size representative of your foot. And shoe sizes are relative to each other. A size 6 is smaller than an 8, and so on. The shoe size has nothing to do with the Time it took to make the shoe.

Relative Sizing uses this same thinking. When you estimate for UX using Relative Size, think of effort, complexity, and risk, not Time (Cohen).

You may be asking yourself, I thought I would become predictable and more accurate with time estimations? How can Relative Sizing accomplish predictably if there is no Time variable? Here’s the trick, we estimate on Size and then track the deliverable through the UX process; we track it based on Start Time and End Time.

By the end of your UX process or cycle, you will have Time data for that Size deliverable. It’s beautiful! One watch out to consider, becoming predictable doesn’t happen overnight; the Relative Size method is a process that can span months; you need to commit. You want to track enough Size data to derive Time ranges for each Size deliverable.

Relative Sizing is a strategy that requires an upfront effort. I recommend a few months of data gathering on deliverables through the UX process. Once you know the Start and End Times for each deliverable and have average Time ranges for each Size, you can confidently provide this as your time estimate.

So, if you are interested in employing Relative Sizing in your UX organization or team, please read on. This article will walk you through Relative Sizing for UX; welcome to the formula for becoming a predictable UX team.

Step 1 — Inventory and Describe

The first step of Relative Sizing is to inventory your UX deliverables and make a list. Get the team together and review your UX deliverables from the past 4 to 6 months and then rank them by the most commonly used to least used order. I recommend defining the deliverables as well. Your definitions should include a brief description, the artifacts created, how it is used in the UX process, when used, and who uses it.

Step 2 — Create Checklists

The next step in the pre-work is to capture the “to-dos” required to create the deliverables. Pick the first five or so deliverables from your list, and for each deliverable, jot down a checklist of steps it will take to complete it.

In the past, my UX team used Microsoft Planner for this exercise (or you could use any other KanBan tool such as Asana or Trello) as seen below in Figure 1 — Planner Task Checklist for User Interviews. We created a card for each deliverable and populated the checklist with the steps needed to finalize the card.

Figure 1 — Planner Task Checklist for User Interviews

Step 3 — Pre Session Preparation

Relative Sizing is a collaborative exercise. The actual Sizing occurs during a voting session. Together, the team determines the Size (small, medium, large, or extra-large) of the UX deliverable based on its risk, complexity, and effort.

Each deliverable is compared to the next, making the Size relative. Team members vote, discuss, and decide on the Size following a consensus model for decision making. As UX leaders, we will be the “hostess with the most-est”; we will lead the session.

Your first consideration is to determine who should attend the session. It’s best to review the checklists for your top 5 deliverables and include everyone involved in completing a deliverable/card. You may need to include Researchers, Visual Designers, Info. Architects, QA, and whoever else may be required. You will need to use a collaborative tool like Mural or Miro to document the team’s decisions.

Whatever collaborative tool you choose, make sure it has a voting feature, which you will use in your Relative Size session.

Relative Size is about coming together in collaborative consensus on the Risk, Complexity, and Effort involved in competing a Deliverable. Notice that Time is not a variable here; it is not essential, not yet. Make sure to book about 45 minutes for the session.

Here’s a quick rundown of things to prepare for the session:

1. Determine the participant list.
2. Prepare the collaborative board; an example of a Sizing board is seen in Figure 2 — Miro Sizing Board. List each deliverable, and under each deliverable, place a Small, Medium, Large, Extra Large.
3. Compose an invite message emphasizing the importance of everyone involved. Include the collaborative board link and set the expectations for the team. Compose an agenda detailing the session’s format to include a quick intro, a review of the descriptions, voting on the Size, discussing discrepancies, and reaching consensus. Make the team aware that this cycle will repeat until all deliverables have a size.

Figure 2 — Miro Sizing Board

Step 4 — Size Voting Facilitation

Whew, the pre-work is done! Now it’s Time for the fun part; hosting the voting session. The team will come together to review each deliverable and vote on the Size (small, medium, large or extra-large). As the host, it is vital to keep in mind the three things necessary for a successful session: time boxing, moderating discussions, and keeping the session moving forward. Remember to have fun and enjoy the debate and discussions.

Here’s what to expect from the session:

1. Start the session with a big thank you for the team, highlighting your gratitude for their participation because you know how valuable their time is. Also, don’t forget to reiterate their importance in determining the sizes and the criticality of the exercise. A little ego-stroking never hurts.
2. Go over the ground rules, the basic etiquette of meetings: be respectful, no talking over each other, etc.
3. Start with the first deliverable, read the description, make sure everyone understands what is involved and required from each person in completing the deliverable.
4. When evaluating, remind the team only to consider the Size based on risk, complexity, and effort and begin the first Voting Session.
5. After about 1 minute (or everyone has voted), close the Voting Session.
6. Pull up the results, and share your screen with the team; please expect some outlier votes. Ask if the outlier voters could speak about why they chose that Size. The idea here is to get the team talking, discussing, and respectfully debating. Sometimes the vote is split 50/50. Get a few volunteers from both sides to talk about their point of view. Only let the discussion last about 2 minutes, no longer than 3. Remember to time box and keep it moving forward. Sometimes you have to re-vote to gain consensus. Document the teams’ vote in the collaborative board and move onto the next deliverable, as illustrated by Figure 3 — Voting Results.
7. Once you are ready to move onto the next deliverable, repeat the above steps. When the voting begins again, the only difference is to remind the team to compare the risk, complexity, and effort to the first. Is it twice as much effort? Three times as much? This comparison is the Relative part. You are comparing and relating the deliverables to each other.
8. Once you have gotten through all of the deliverables (or your 45 minutes are up), it is time to close out the session. Depending on the amount of discussion, discrepancies, and re-voting, you may need to schedule a second session. If not, you now have the Relative Size for each deliverable with the consensus of the team. Thank the team again for their time and participation. Let them know of the next steps, tracking the Sized deliverables through the UX process phases.

Figure 3 — Voting Results

Step 5 — Tracking the Sizes

So now what? At this point, the team now has a deep understanding of each deliverable in terms of risk, complexity, and effort, but what to do with the Sizes? Remember the Planner board you created earlier with each UX deliverable and checklist? It’s Time to open that up and create a template, and you can call it “UX Team Template.”

On each card, put the Size of the deliverable in the Notes, as pictured in Figure 4 — Card Sizes. Rally the UX team and request to use the Planner board as a base for their next projects. At the start of every project, begin with duplicating the “UX Team Template,” remind them to rename it to fit the project, and they can create the backlog of UX deliverables.

You can look at all of the template's deliverables, delete the ones you will not need on the project, and duplicate those you need more than once. Once you kick off the project and start moving cards in the process’s progression, you should comment on the card saying something like “moving onto Design Phase,” which creates a date/time stamp (Figure 5 — Comments).

Set this standard for the team, and each deliverable will be date/time stamped every time it moves to a different UX phase.

After a deliverable has moved through all the phases, and you have a timestamp of how long a card stayed in a phase, you now have cycle time and can tie your relative Size to Time. It takes a bit of work to go through the comments and derive the data, but it is well worth the effort. This phased Start and End Time is concrete data on how long each Size takes to get through the UX process.

Figure 4 — Card Sizes

Figure 5 — Comments

Step 6 — Impact and Results

After 3–4 months, you should have enough data to calculate:

1. Duration- How long each Size takes to get through the entire process
2. Cycle Time -how long each Size takes to go through a particular phase of the UX process

This data makes UX predictable. Your product teams will thank you, and they may even buy you lunch! Now, you and your team can spend less time trying to estimate and more time UX-ing.

Relative Sizing accomplishes a lot, below are some benefits:

1. Standardize UX deliverables (deliverable lists & descriptions)
2. Standardize how to do the work based on checklists (Planner Template)
3. Set expectations with the entire team (Voting Sessions)
4. Provide a platform for individuals to have a voice, a chance to be heard, and to shape the process (Voting Sessions, discrepancy discussion, and consensus)
5. Rollup to Size entire UX Portfolios
6. Create a stable UX team

I want to emphasize how paramount it is to document your team’s value. UX is sometimes hard to quantify. I recommend breadcrumbing throughout this process to create a trail for your leadership. Many times, the value of Relative Sizing is not realized until long after the exercise takes place. You want to ensure leadership’s visibility into Relative Sizing for UX. Make the process explicit and transparent.

As you go through each step, create artifacts that show progress, like screenshots, voting results, size/time ranges; whatever will help you communicate your progress in Relative Sizing to your leadership. Relative Sizing requires upfront work that returns a ton of value for the organization.

Efficiency comes into play when time commitments of engaging with UX is understood across the business. Resourcing, Planning product rollouts, all of it is dependent on UX. Relative Sizing assists UX in becoming reliable, predictable, and reputable.

In closing, Relative Sizing for UX is not a perfect science, but it gets us closer to that bullseye. By shifting our mindset away from Time and focusing the team on what is important; the risk, the complexity, and the effort to complete a UX deliverable, we accomplish much more than a Time estimate.

Effectively we level set together as a team and strengthen our UX cohesion across the organization. Orchestrating UX and working cross-functionally is full of challenges and obstacles. Relative Sizing can help navigate and chart the waters of UX estimation and ease the angst of scheduling. I hope you found this article useful, and, as always, I wish all UX practitioners success in their endeavors!