Improving design’s planning process

The problems we were facing

The company used the SAFe method of agile, and the quarterly planning process made planning design work difficult. At the time, the planning was in Europe over two days, so the design team could only send the DPM and me to participate. During planning, some pain points surfaced:

• ⚠️ One person (me) decided how the team would do the design work. It’s not how I liked to design, nor should it be how design is done.
• ⚠️ The team couldn’t get real-time updates. With a 6-hour time difference, any updates would be quickly outdated and there was very little opportunity for feedback.
• ⚠️ Planning design work was very reactive. We had to juggle design requests from up to 15 scrum teams and work within delivery and time constraints.

As we worked through the quarter, more pain points surfaced from the rushed planning:

• ⚠️ Designers had to quickly ramp up on the context for the work, which ate into design time.
• ⚠️ During this unpacking, designers uncovered more questions and issues that affected the scope.
• ⚠️ At times, the design work felt very production-heavy.
• ⚠️ Some designers struggled with the chosen activities or preferred different solutions but didn’t get a chance to pivot to them.

While the team delivered great work, it wasn’t without its hurdles, and I knew we weren’t designing to our fullest potential.

The challenge I needed to solve

It was tough to navigate these quarters. As a design manager, it was my responsibility to figure out how to remove these pain points and create a space for my team to thrive. So, I was looking for a solution to ensure:

• The team has better context around the work needed
• They are confident and excited about the solutions
• Their ideas and approaches fit the scope of their abilities and our timeframe.

Including the entire team for planning seemed to be an easy win for the first two items. Solving for the last item would be more challenging, but after some thinking, I figured out an option.

The potential solution—story pointing design work

Could story pointing improve planning for designers? If we could story point our work, theoretically:

• Designers could have a better say in their approach and solutions. For example, they could break down the steps they’d like to take to create a design solution they’d feel comfortable doing.
• The DPM and I could ensure the scope and timing were realistic. Understanding the effort (i.e., story points), we could see if this was feasible, who could take on more work, or who we could pair together as needed.
• Our design team would speak the same language as PM and Engineering. While story points are nuanced to every team, we could roughly articulate why something was too much work to fit in a sprint or how we might adjust work. (Prior to this, we used t-shirt sizing and that didn’t resonate well).

At this point, we had nothing to lose if we tried this. So I set off to figure out how to approach story pointing design work.

Could story pointing improve planning for designers?

Creating the solution

My goal was to try out story pointing for the next planning session. That gave me a few weeks to figure out what story pointing looked like for the team. I used my UX skills to do some research and generate some ideas.

• Research: I searched online for how this might work and didn’t find anything related to design. I spoke with SAFe experts, and they just seemed confused (SAFe diminishes the value of UX, so for them, I wasn’t doing something that was part of the official training.). I reached out to an engineer (who was familiar with our work) for his perspective on how newly formed teams or entry-level engineers learned story pointing. That gave me a lot go by!
• Ideating: I sketched several ideas on story pointing—what do 1, 2, 3, or 5 points mean? Do we go up to 8 points? I aligned actual work to the point system. Once I had something, I ran the ideas by the same engineer for feedback and any tips or things that could help us.
• Constantly communicating: The design team knew I was working on this, and I’d share rough drafts and provide updates. Trying something this different is a risk, and I wanted them to feel comfortable with what was going on as I explored solutions.

Preparing the team

Quarterly planning was coming up and I needed to do two things:

• Get the team up to speed on the planning experience
• Teach them our story pointing framework

This would be many of the team’s first time participating in quarterly planning in addition to trying out story pointing. I created a PowerPoint deck to serve as a “playbook” that I could present from, but also something they could reference later. I used PowerPoint because it was more visual and there was such a stigma around our Confluence instance that I didn’t want that baggage affecting this effort.

The playbook included:

• What to expect with planning—guidelines, meeting with scrum teams, daily rituals, etc.
• What story points look like for design work
• Different variations of sprint workload for individuals
• How previous work they did would translate to story points
• A space for questions and answers

I thanked them for being so willing to try this and also let them know that if this didn’t work out, we could try something else. To this day, I still appreciate how much they trusted me and were willing to give things a shot. 🥹

Story pointing and planning in action

Planning took place in May 2020, so we were all online. Because we were working across multiple time zones, instead of two days, planning stretched into five days. This gave us a lot more flexibility to try this out. That week, the team:

• Met with scrum teams to understand work, ask questions, and provide ideas
• Defined the activities they’d like to try to create the solution (e.g., audit, interviews, etc.)
• Articulated their work in story points
• Negotiated the timing of deliverables

For planning, we worked off of a Miro board, which got very messy, but it was extremely helpful in having a shared area for notes and for the scrum teams to see. Overall, planning was exhausting and actually fun. Story points seemed to work out well as a framework for articulating and scoping work. We all had a clearer understanding of the work needed and what we were committing to.

Overall impact

Most immediately, this made a huge difference with the team. The design director of our product area heard about the success of this effort, and I was asked to introduce it to the rest of our product area the following quarter.

🎯 Impacts to the team

• Designers immediately had more confidence in their work.
• We could pivot with ease as issues arose.
• We could provide growth opportunities—seeing everyone’s work in story points meant we could find moments to pair more senior designers with inexperienced ones.
• Designers were excited about their work—they weren’t cogs in a feature factory. Instead, they could do the innovating they were capable of.

🎯 Impacts to the product area

• We established trust with PM and Engineering—with the design team fully being involved with the planning process, they understood us better.
• We were invited and included in strategic discussions and meetings—as opposed to having to invite ourselves or being omitted.

🎯 Impacts to the entire company

• After two successful quarters, I was asked to scale this process and framework to support the rest of the design org.
• The design org became more visible within the SAFe framework.

Personal takeaways

• As a manager, this gave me a lot more confidence with navigating uncharted territory. There's so much training around SAFe, that it's easy to think, "this is how it has to be." But there are times when not following the status quo can be even more beneficial.
• I honed my multipler skills. As part of a leadership class I took, we learned about two leadership styles—one that can diminish a team's talent and one that can amplify the team's strengths. This was an opportunity for me to practice skills to empower my team to identify design solutions.