Help Center

Story pointing design work for your design system

Michelle Chin

When I propose story pointing design work as a solution, I always get asked, “Can you really story point design work? That seems difficult.” The answer is, “Yes, and it’s not as difficult as you think.” Story pointing design work effectively allows designers to communicate with peers, managers, program managers, and more. When considering design systems, story pointing can help teams understand and track the many steps, parts, and reviews needed for adding a component or pattern to the design system.

Story pointing is especially helpful if the design system team is federated, works on other product work, and has no choice but to run scrappy. By story pointing, everyone can get a sense of how much work there is and then see how to integrate it into their existing workload. When you can articulate how much effort or how long something will take, it’s much easier for peers, managers, and stakeholders to understand, empathize, or even help negotiate priorities to solve problems. (Ideally, the whole design org would story point their work to speak the same language. And if you can influence it, I would consider scaling story pointing.)

I’ve taught several smaller design teams how to story point design work, and we’ve also scaled this method design org-wide. So I’ve seen what works and what doesn’t. This article captures some of my best practices and things to avoid.

What is story pointing?

Before we jump into story pointing, let’s talk about what story pointing is. Story pointing estimates the effort of completing a task based on complexity, scope, and risk. For this, we make estimations in terms of points, which follow a Fibonacci sequence (1, 2, 3, 5, 8, etc.). The smaller the point size, the less work or risk to complete. Story pointing is a common tool used in Agile development. Developers estimate work based on story points, and teams can track how many points they can take on in a sprint.

The biggest takeaway to remember is that it’s an estimation tool to help teams better understand how much work they have on their plate. If they realize it’s too much, then they might need to rescope things to fit within a timeframe or expect the work to take longer.

How does story pointing work for design?

You can try story pointing out in any planning sessions with your team. (Some teams call it planning poker.) Even if teams aren’t following Agile, it’s common for teams to work in two-week sprints. Based on this cycle, the team can story point their work for that period.

Like pointing developer work, your design team meets and reviews the task. The team will estimate how many points the task is worth for each task. Initially, it might be hard to align on points because it’s a new concept. But if you get an array of vastly different answers, it’s an opportunity to dig deeper. For example, if a few people say the task is worth one point and a few say it’s worth five, there could be a risk that some people are considering.

When assigning a point value to a task, consider any internal or external reviews for the work and any time needed to make updates. For example, if you’re designing an alert component, consider how much effort it will take to sketch out, design in Figma, get feedback from peers, have time to update the design, create the component with variables, etc. Think holistically about the workflow process, not just the heads-down computer work.

Here’s a basic guide on how your team can think of point estimates to get started:

• One point – When starting, your team can think of one point equaling one day’s worth of work. When we say one day’s worth of work, we’re counting actual working time, not a full eight-hour day. So this can be anywhere from 4-6 hours, which gives the person a buffer to attend meetings, answer messages, etc. One-point work is usually clearly defined and low risk. As the team gets more comfortable pointing, avoid counting values as equivalents for “days of work.”
• Two points – can feel too nuanced between one and three points. When starting, I usually skip this value until (3-4 months into the process) the team gets a good feel for what one point and three points mean.
• Three points – can be considered small work, more complex, but still low risk.
• Five points – can be thought of as more complex and as medium effort work, and the value accounts for risk and unknowns
• Eight points – Some dev teams will go as high as eight points, but I skip this value. If someone identifies a task as eight points, it usually means it is too large, and they can break down the task smaller. Those smaller tasks can then get pointed. It’s easier to fit work into two-week sprints when the team can break things down into smaller tasks. Claiming something will take eight points is vague and equivalent to arbitrarily saying, “Oh, I can get this done in three weeks, probably.” The goal of story pointing is to get people on the same page about the work needed and its scope.

It might help to show examples of what point values can look like to help the team get started. These are the diagrams I used when teaching teams to story point. It helps them get a rough sense of the work for each value.

This diagram shows the rough expectation of work for the different point values.

This diagram shows the work from a timeline perspective (e.g., designers do some work, conduct reviews, make changes, and then deliver).

If you’re a DPM, work with the Design Manager or Lead to estimate how many points each person should have. When I started story pointing with my team, we estimated 6-8 points per person in a sprint. It felt really conservative, but it was at the start of the pandemic, and there were a lot of distractions. I also wanted to avoid overloading the team with too much work. If they had extra time, there would always be things they could do from the backlog.

A point range per person is also helpful because not all workloads might look the same. It could be that Person A has six 1-point tasks for a total of 6 points, and Person B has one 5-point task and one 3-point task for a total of 8 points. While the first person seems to be taking on less work, we’re considering the amount of context-switching they’ll need to do when covering all those tasks.

This is a visual example of Person A’s and Person B’s workloads. Person A has fewer points this sprint because they are context-switching more than Person B.

Points are estimates and are unique to every team. After some time, your team will organically understand what points mean for your team’s work. Keep in mind anytime someone joins or leaves the team, the points might need to be recalibrated (e.g., If someone familiar with accessibility leaves, it might take others more points to do work now. Or if a new person joins, they might need more points until they find their stride.)

As you estimate work, you can easily document this in any project-tracking app your team uses. In my case, we used Jira and added the story point estimation to the ticket. What’s also nice is that devs could see our tickets and see how many story points we allotted. Even though they were on a different scale (because story pointing weighting is unique to each team), it could give them a sense of how much effort the work would take. (It’s also a great way to demonstrate that design teams don’t just magically whip things up instantly, and the work takes critical thinking and effort).

But what about…

Hopefully, the way I talk about story pointing makes things sound easy. But I’m sure you have questions or thoughts. Most of the friction comes from people trying to align their mental model for this to how dev teams point. Instead, it’s best to disassociate what we’re trying to do here from what they do. Start with a fresh mindset, and it’ll make things easier.

Here are the most common questions or thoughts people want to discuss, in case you’re interested in navigating past them.

• What about calculating velocity or looking at burndown charts? You could do this, especially if you have the staffing to support this additional tracking. You also don’t have to do this immediately. Once the team finds its stride, you scale the process to include this. In my experience, just estimating the work and talking about how well we did in period retros has been helpful enough.
• Design work isn’t straightforward* like dev work – there’s so much unknown for us! How can we possibly story point? I hear this a lot with concept work that involves usability testing. There’s always a fear of, “What if we need to pivot and start over again?” While that is a risk, you can still break down the tasks that need to be done (e.g., create a design, create a prototype, pilot the usability test, etc.), which are concrete enough to be pointed. If you’re pointing within two-week sprints, that should be a small enough timeframe; if you have to pivot, you can plan the pivot in the next sprint. (*Truth be told, dev work isn’t always straightforward either. They usually have to do their own discovery and research, and they’ll point this out accordingly, too.)
• I have a mix of junior and senior designers on my team. Giving everyone the same amount of story points seems impossible or unfair. Starting everyone off at the same range will help the team establish what the point values mean. From there, the team will naturally find a flow. You’ll also get a sense of who has more or less capacity. This might mean senior designers can take on more work or more complicated efforts with more unknowns and bigger risks. This might mean junior designers take on work within their capabilities, and if they’re given an opportunity to do more complicated work, the work is pointed higher. It comes down to story points being an estimation tool for the team to understand what they’re capable of accomplishing.
• Do I need to use a dev tracking tool like Jira now? I recommend using whatever tool you’re currently using and feel comfortable with. Focus on story pointing as a framework you can apply to your existing tools. This will help lessen the change your team has to adapt to. If your engineering teams use a tool like Jira, it might be worth considering if it benefits team collaboration and communication.

Top tips

Here are a few tips to help ensure a successful start:

• If you have a large team, consider piloting story pointing with a smaller group of people. This way, you and the team can work out any hiccups before scaling it with the larger team. It’s also a great opportunity for other teams to observe how things are done and feel more comfortable when the program is scaled across the team.
• Consider estimating on the higher side if there’s any hesitancy for an estimate on a task. Story pointing is just an estimate, not something set in stone. If the person finishes their task earlier than expected, they can do additional work. It’s much better to be in that position than scrambling without enough time.
• Strive for 80% capacity at most. Capacity is the amount of “space” someone has within a given timeframe (e.g., a two-week sprint). Everything rarely goes as planned in real life, so keep capacity under 80% to allow for anything that might crop up (e.g., family emergencies, cloud-based tools going down, etc.).
• Don’t forget to account for public holidays, employee time off, and other big chunks of time. At the start of planning, double-check to see which days teammates won’t be in. This will affect how much work they take on in a sprint. Check if any team off-sites, org-wide town halls, etc., could cut into working time and adjust the average points per person accordingly.
• Design managers should facilitate a healthy discussion to figure out estimates. Sometimes an individual will underestimate how much work a task is when you know they need to story point things higher. In this situation, as a manager, have them talk through the steps it would take them to do the work and see if that realistically aligns with their initial estimate. Point out what aspects might increase the workload. Typically, they can see how they might need more time, and you can both agree on assigning the work a higher value.
• Working cadence, support work (and half-point values). We tried to fit work into two-week sprints as much as possible, which included time for any reviews. We didn’t realize that our working cadence for PM and Engineering reviews often fell outside of the sprint. To work around this, we added one point to the next sprint to accommodate reviews and changes after the initial design. We also didn’t anticipate that our engineering teams couldn’t implement the work during that two-week sprint. So usually, a sprint or two later, when the devs could code the designs, designers were QAing designs and answering questions. For this, we started using half-point values to set aside time for the designer to manage this. It roughly comes out to be 2-3 hours a sprint to provide feedback and make adjustments. Sometimes the time wasn’t used or was only partially used. With any spare time, the designer could focus on other tasks or pick up something from the backlog.

The additional benefit of story pointing – empowering makers

I’ve briefly touched on how story pointing is an excellent tool for teammates to align and speak the same language and how it can help us ensure the team doesn’t take on too much work. One of the most significant benefits of story pointing is that it empowers the designers, developers, or writers to identify how they’d like to approach the work in a comfortable timeframe.

As a manager in a previous company, I was responsible for estimating the work, tasks, and timeframe. I was good at defining this for how I worked, but how I worked was not how everyone else worked. This led to over and under-estimated scoping and approaches that designers wouldn’t have taken. When we adopted story pointing, it put the team in the driver’s seat. It led to more accurate scoping and design activities that were better for the designers—overall, it led to much better outcomes. As a team, we could better negotiate if we had to change approaches and articulate why. And as a manager, I could spend more time on mentoring and coaching design approaches, methods, etc.

Give story pointing a try; you don’t have much to lose.

If you’re struggling with scoping components after prioritizing them, meeting deadlines, setting expectations, or fitting in design system work, give it a try. Even if it’s for a month-long pilot. If it doesn’t work, you can always try something new. When my teammates and I first tried it, we were all hesitant, but we tried it, and we couldn’t live without it!

If you try it or have questions, let us know! I’m always happy to chat about story pointing design work. You can find me on LinkedIn or zheroes, our Slack community.

DesignOps for Design Systems

This is one of many articles we’ll be writing about when it comes to leveraging DesignOps for design systems. If you have questions about how your design system can be managed better through DesignOps, feel free to contact us.