Story Pointing Our Design Work

One of the toughest things to handle as a manager is doing something you know isn’t what’s best for the team. I was missing the mark on how we planned work, felt terrible, and knew I had to fix it. Before I go into the solution, let’s dive into the scenario we were in.

Our product area follows SAFe. Each quarter, the design managers and program managers attend PI Planning. Due to travel costs, only those two roles get to travel. During this time, we figure out what work our design team would commit to for the next quarter. Since the planning sessions were in Europe, it was often too early to collaborate.

At planning, the Program Manager and I would scope any design work with the scrum teams. This made sense; we’re a close duo, who could gut check each other on design methods, scope, and timing.

After planning, we briefed the design team, “Hey, this is what we’re working on this quarter. Here’s who’s working on what. And here’s how long it should take you.”

In-Person PI Planning Kick Off Session
This is the in-person PI Planning kick off (at our Prague office)

Inflection Point

We were always in “go” mode; we felt like we didn’t have much choice but to handle things this way. Delivering this update always felt jarring. Our designers looked stunned, but to their credit, they rolled with it as best they could. So over the next quarter, we roughly tried to go as planned, adjusting a little here and there. When talking to them about it, I realized how bad this was. Here’s what I discovered:

  • Our designers lacked context to make design decisions to move forward
  • They didn’t have context on how projects appeared, disappeared, shuffled, or assigned
  • Most importantly, they wanted to approach solutions differently than I planned – this changed the original time scoped

I thanked them for their honesty and inside I felt terrible. This used to happen to me as a product designer and it never felt great not having a say in how you’d approach your work. 

The Solution

I had to change how this was going. I decided to have them take part in the next PI Planning. COVID actually gave us an opportunity to make this work. We weren’t able to travel. Since it was going to be remote, everyone could easily participate. There was a bit of a time shift, but at least we could all participate.

I wanted the team to have full context and feel empowered to determine their design approaches to these projects. At the same time, I needed to provide some guardrails so they could be successful at planning.

To prepare them for success, I set up a structure for how our design team would participate in PI Planning. This included kick-offs, office hours, working sessions, etc. I also created a story pointing framework that considered “maker” time, reviews, and buffers for risks. I roughly estimated how much capacity we should take on as a guardrail.

Sample story pointing scale for design
Slide from my Intro to Design Story Pointing presentation. This breaks down the expectations of how much work is involved for the different point breakdowns.

Applying Multiplier Experiments

Cover of the Multipliers book

PI Planning is very intense and timebound, so it’s very easy to go into rescue mode and start making decisions. Behind the scenes, I really wanted the team to own their work and this process. It was critical that I wasn’t too involved or too aloof. To help with that, I listened to the Multipliers audiobook. Multipliers is a concept where leaders “multiply” the capabilities and smarts of teams to inspire and solve problems. This gave me a framework I could rely on during planning to ensure I was empowering them. 

I picked a few Multipliers experiments to try, including:

  • Play fewer chips
  • Make space for mistakes
  • Ask the questions
  • Give it back

I was pretty excited to try so many new things at once. I was still a little nervous because this is a lot of change. But my team has built a lot of trust, which allows us to handle changes and challenges with confidence.

PI Planning – The Moment of Truth

Before PI Planning, I reviewed expectations with the team and walked through story pointing. I gave us an eject button, “This is an experiment. We’ll see how it goes and if it doesn’t work, we’ll try something else.” Honestly, I was more nervous than they were about it – they seemed to feel pretty good.

During PI Planning we met a lot, talked through a lot, and had project priorities shift on us. Despite how exhausting planning is, the team brainstormed approaches and story pointed their work. I held to my Multiplier experiments, “How do you imagine approaching this feature? What information are you missing? How many story points do you think this should be?”

We built in a few guardrails for us:

  • Not committing to too much in a sprint
  • Keeping some buffer time to the end of the quarter in case stuff slipped
  • And I stepped as needed, but it was rare.
Sample story pointing scale for design
Slide from the Intro to Design Story Pointing preso – showing the typical cadence of various story sizes.

Success, in that moment

Example PI Planning Miro Board
Screenshot of our PI Planning Miro board

Overall, we did extremely well for our first shot at this new method! It was draining, but everyone felt happy and confident in the end. The designers had better visibility around projects, assignments, and scope. They felt confident in their approach and the pointing felt reasonable to everyone.

For me, I achieved a solution that empowered and brought out the best in our team. The most exciting part was when one designer was raving about this to my manager.

Even though PI Planning went well, we knew that true success would be in how the next quarter played out.

(Screenshot is intentionally blurry looking)

What happened?

Looking back at the quarter, I’d say 80% of things went smoothly. We hit some unforeseen circumstances but had enough buffer to pivot and cover. Some projects switched on us and we pivoted on that, too. Story pointing worked, but we learned some stories kept coming back from the dead. Next time, we need to allow more capacity for that.

The biggest success was when we scaled this process to our other areas of Citrix Workspace! Our broader team shared the empowerment and energy by having a better say in their work.

We still have some tweaks to make and we’re finding our stride. In the long run, this approach gives us data around our capacity. We can confidently understand our capacity and make data-driven decisions around headcount needs.


via GIPHY