Agile sprints for CX

Steph Hardy I really like the idea of the framework and what it could do for a team, but it's usually very product or engineering focused. I was just thinking one day, well, what if a sprint could work for a CS org? What could that look like, and what parts of the process would we have to mold or ditch that just don't fit?

Jen Weaver Welcome to Live Chat with Jen Weaver. Work with customers can feel endless. Emails in, emails out, weekly meetings, metrics dashboards. It's like the dishes — we're the dish doers. But what if we could borrow an idea from other teams that would give some structure to that work, that would allow us to feel like we have completed something?

Well, enter Steph Hardy. Steph is a customer solutions engineer at Guru who has been working in the customer space across various industries for over a decade. She started in luxury hotels, transitioned into tech, and was a Guru customer before even joining the team. She's an incredible go-getter and I have looked up to her for years — she taught me a lot of what I know about customer work.

And after this episode you can copy her process here too. We're giving you the exact playbook, a CSV file to create your plan just like Steph did, and clear meeting agendas to keep it going. Let's dive in.

Steph First we sort of wanted to decide, where are we spending our time today? Because we can have new ideas for days, but can we actually execute on them, and are they going to make a difference?

So we used sprints as a way to take a step back and analyze, as a CS person, what am I actually spending my time on day to day, and does that align or is that different from my other CS colleague?

We're a pretty small but mighty team, and each of us decided to spend a couple of months dedicated to this idea of, let's actually capture the activities that we're doing. At a bare minimum, just write it down: what are we doing? And the way that we decided to do that was through an agile sprint sort of format.

Jen Ah, that comes to our topic. So can you dig into how you created that, how you decided to launch it?

Steph I think it was back when I was looking to transition to tech that I was taking some courses, and I took a General Assembly course on agile methodology. And it stuck with me, all these years later.

I really like the idea of the framework and what it could do for a team, but it's usually very product or engineering focused. I was just thinking one day, well, what if a sprint could work for a CS org? What could that look like, and what parts of the process would we have to mold or ditch that just don't fit the dynamic and sometimes reactive world of a customer solutions or success team?

So I had this idea to do these sprints, and I had this hunch that it could be interesting or helpful for our team. But it was really just that — it was just an idea. And I was hesitant to go to my director and pitch it without having a solid reason, because in my mind I was like, oh, this is just a cool experiment where maybe we could work more efficiently. I like trying a framework. I love frameworks, I love anything with structure. And bonus if it's color-coded, right?

Jen Totally. And sometimes it's to a fault. I've recognized that I used to want to operationalize everything. Maybe other folks will resonate with that.

Steph Yeah, I used to just want to operationalize everything.

Jen It's tough when things change rapidly, because you've just spent some time operationalizing something and then it either needs to be scrapped or just redone. So you have to kind of know it's going to be a durable process.

Steph Totally.

Jen So you had this idea, but it sounds like effectively it amounted to managing your peers if you were to implement this. So where did you go from there, from that feeling of "is this my place?"

Steph I had the idea, and sort of serendipitously, during a one-on-one with my director, she mentioned some friction points that she was seeing. She was describing the pain of, how are we spending our time, and are the things that we're working on making an impact?

I think she was even mentioning the idea of, our platform has changed so much, leadership is really keen to understand how customers are reacting to that, or what are the projects that we are spending our time on because a customer needs our help with a specific part of the product and implementing that new feature or enhancement.

So she's describing all of these bumps in the road, and very naturally I was able to be like, well, I've actually been thinking about this thing — what if we tried sprints?

I think she resonated with it pretty quickly, because she was coming to me with a problem that she was looking to solve and I had an idea for maybe something that we could try. And we're pretty experimental and agile as a company.

I should also mention, another department — our marketing team — had been working in sprints for quite some time. I actually met with our creative director and our head of marketing to talk about what she liked about it. What had the sprints done for her team, what had it done for the business, but what had it done for team morale?

Jen So let's dive into the template. We're sharing a generic template that's based on what you created, so anybody listening or watching can go off of that. Can you walk us through how you used it?

Steph I will say that when I had this idea to do sprints, the next question — as always when you're trying to operationalize anything — is what tool am I going to use?

And honestly, I stopped myself from going down a massive rabbit hole of where should this thing live. I was sort of proud of myself, because a couple of years ago Steph would have been like, let me do a deep dive and compare every single project management platform that's out there — even if our company hasn't budgeted for it, and I didn't even ask if there's budget for it, and I'm just going to start doing this, and what other features does this tool have, and how could I make it the best that it could be?

There's always going to be a million tools. That wasn't what was important. It was, how can we get this up and running pretty quickly and low lift?

And I mentioned change management earlier — I didn't want my team to think, oh, another thing to juggle in my day. That's the "what's in it for me" thing again. It needs to be easy, it needs to be seamless.

Jen Needs to be easy, needs to be seamless.

Steph Part of that is existing in their current workflow. Not another tool that they have to go to — which is something we preach at Guru all the time about our own platform. So just walking the walk and talking that talk.

I decided to create the sprints in Slack, because Slack now has what they call lists. Slack lists is basically a project management spreadsheet sort of format right within Slack. And we used Slack a ton.

Jen It was perfect.

Steph So I was like, all right, better than maybe a Google Sheet. A little bit more dynamic and a little bit more fun, because it's just right in Slack and there's cool little alerts you can set up and things that go off in a channel.

Jen That's perfect, your team is already there all the time. Did you sort of sketch this out on paper, or did you open up a private list in Slack and just play with it?

Steph I opened up a private list in Slack and just started playing with it. I'm definitely a learn-by-doing-and-building type of person, so I just went in and started tinkering and playing around with it. And it's pretty simple, the format. It's really nothing fancy.

I guess before I started building, I was taking the information from my experience with an agile methodology course from years back. Something had resonated with me about the methodology, but I definitely wasn't an expert — I took one course.

So I actually used ChatGPT to help me brainstorm: what are the key aspects of a sprint process? In an agile process you have your planning phase, you have the creation of the actual items, for each item is it a small, medium, or heavy lift, applying some sort of point system to items, assigning them out, executing on it, and then doing a retro. Those are more or less the main key components of the sprint.

I used ChatGPT to remind me of those components, and then to help me think through, well, we're a customer solutions team, here's a bit about the team, and how could I maybe apply this framework to our model? That was just my brainstorming.

Jen That's the new world of GenAI, right? We have this ability to have a dialogue basically with ourselves, but also with a robot.

Steph But yeah, that was how I started to think through how we would apply a sprint to our team in real terms. It wasn't just this idea floating any more, I was starting to solidify it. And then from there I started tinkering in Slack lists to see how I could build it out.

Jen A couple of questions. One is, what were the units in this sprint? Were they customer education projects that you were about to take on, or specific customer activities?

Steph We were looking to capture any activity that we were doing with a customer, essentially.

What it did turn into — and this is something that I definitely want to talk about — is the idea that once we started to document "okay, how am I spending my time with customers, what am I talking to them about," we knew that we were taking calls with customers, we knew that we were answering emails, we even had some shared Slack channels with customers, and we had data on the volume of things. But there was no actual context, that qualitative context of what's happening on those calls.

We can listen to a transcript, we can also look at AI note takers. But as a human being, what am I working on with each customer, and what are the trends that we're seeing? Where am I actually spending a majority of my time?

We can look at all of that data, but there is just something different about me being like, hey, this week I only worked on these three things, and I have 70 customers that I'm responsible for. So what are those things that are taking up our time? And then we can start to analyze that — is where we're spending our time where we want to be spending our time? Is it best for the business to spend our time in these places?

Once we started to do that gathering through the sprints, then we were able to really see that there were themes. And from those themes, that's when we started to say, let's start hosting workshops or webinars with our customers where anyone can attend. It's not in person, it's online, but can we create that same sort of in-person experience where we're educating customers on features online? And if we're going to do that, what are the top topics that everyone needs to know about right now, based on the trends of the sprints that we were looking at?

Jen That does make sense. So you were asking your team members to essentially log their time and keep a running list of what they did, and then plug that into the sprint framework. Am I getting that right?

Steph Sort of. Because we were using an agile sprint framework, there is a sprint planning process. So what we were doing was, I was challenging the team to think a bit proactively and strategically.

We were finding ourselves in a very reactive space, where our product had changed a lot, customers were maybe curious about a feature and wanted to learn about it, or running into a pain point because they're not used to using a certain part of our product. We would get a lot of inbound requests from that.

I was really challenging my team to take a step back from that reactive motion and say: when you look at your customer book, and you know our product, and you know what's coming out and what recently came out, and you know your customers pretty well from a year plus of working with them — what do you anticipate that you're going to be working on with your book this month?

That's the sprint planning phase. Where do I think I'm going to spend my time?

And now, we all know customer-facing roles, you have to be flexible. So we're taking a moment to pause as a team and think: how do I want to spend my time this month? What are the things I really want to get done? What am I committed to saying I'm going to try to do? At a very bare minimum, what am I going to say I'm going to try to complete — because we know anything could happen, and we have to be able to be flexible and react to things that come up.

But let's try that. Let's sit down and have a planning session where we just try to be proactive and strategic about where we want to spend our time.

And then as the month goes on, when things do come up, if it's something that you did spend a significant amount of time on — and that's arbitrary, it's up to each person to decide. We weren't over-operationalizing. It wasn't meant to be "log every activity," it was just meant to be "think about what you want to do." If something comes up and you actually spent a decent amount of time on it, let's get that added.

And then we had a field for them to mark the date that they added it, so that it was reflected that it wasn't a part of their original plan, but it came up and they did spend time there. And then you could justify, based on the final list at the end of the month when we'd go through our retro — you could justify if something didn't get done. It was pretty obvious why, most of the time.

Jen You're totally uncovering these things that people are spending time on that they didn't predict they would have to spend time on. That's really interesting.

So you did that by inviting them to this Slack list where they could add both their predictions and what they want to work on, and then also add "oh, on the 18th of the month this came up and I need to add it because I'm spending significant time on it."

Did you find that went well? Were people just like, "I'm here for it, I'm going to add things"? Or were there tweaks you made along the way?

Steph It worked pretty well. Like I said, I didn't want the team to think "oh, another thing, another responsibility, another thing for me to do," which is why I created it in Slack, so it was right in their workflow.

And then I would run that meeting. I would basically lead the team through a brainstorming exercise to get them thinking, pose questions. Some of the questions were the same every month, some of the questions would be different depending on what was going on in the business.

I was always consulting my director on how I was actually running this process — because again, I'm not the leader of our department, and I didn't want to step on toes, and I wanted to be open to feedback. I wanted to learn and grow through the process.

So I'd lead the team through that brainstorm, and then we would come back together and start to talk about the tasks that we were thinking, the activities that we were thinking we were going to focus on. And it always sparked ideas too. If I was hearing my colleague Matt share that he was going to work on something with one customer, and another teammate was saying that she was going to work on something else with her customer, then I would be like, oh, that's a great idea. Do I have any customers who might be interested in that? Or I hadn't thought of that, maybe I should carve out time for that.

Jen It sounds like that meeting in itself was just incredibly valuable.

Steph For sure. Everyone has this habit of having meetings that — do they actually serve a purpose? Having a team meeting just to say we have a team meeting isn't super helpful. What are we actually discussing during that team meeting?

So the sprint planning meeting was really valuable. Even if we stopped there and didn't write the items down in the sprint, it was just a good place for the team to air things out and relate to each other.

Jen And you did that monthly?

Steph We did that monthly.

Jen So you did that to kick off the month. And then did you do just sort of Slack engagement about the process throughout the month?

Steph When we first started the sprint process, I asked the team for feedback on standups, because standups are a part of the agile framework. And part of my initial ideation, I was thinking to myself, daily standups is definitely unnecessary for us. Again, I was conscious of not wanting to burn my team out with any major changes. I wanted to make this as seamless as possible, so I knew right away daily standups was not going to fly for the team.

Jen So the daily standups in agile — just to make sure I understand — it's kind of like showing up in a Slack comment and saying "this is what I plan to work on today"?

Steph Standups can be either synchronous or asynchronous. There is a daily synchronous standup —

Jen Sounds like a lot.

Steph It can be, and that can be really popular for engineers. But the purpose of it is mostly, am I blocked on anything? So you'll come to the meeting and say, "I can't move forward on this, can someone help me out?" And you're getting that on everyone's radar and able to move past it.

Jen So what cadence ended up working for your customer team?

Steph We decided, instead of doing daily standups or anything synchronous, to have an asynchronous Slack reminder. I think it was just once every two weeks.

Jen Like the middle of the month, "how's it been going, you're halfway through."

Steph Exactly, yep. If I remember correctly we might have set it up at first to be weekly, and then — never mind, let's just do every two weeks. When you're working with more complex accounts, things are slower moving. So is it really necessary to ask the team to provide updates once a week during a four-week sprint? Because we were doing our sprints monthly as well, which is worth mentioning.

Jen And a meeting at the end of the month that was both a wrap-up and the setup for the next month? Or two separate meetings for that?

Steph We kept that separate. We kept the sprint retro separate from the planning session. That was one, to not make a meeting too long, but also to have those exist as separate ways to use your brain — at least that's the way I thought about it.

More often than not, our retros were more about what should we start, stop, or continue doing as a team. What about this process do we want to start, stop, or continue doing? What about that is causing friction?

One of the things that came up that we should stop doing was the weekly Slack reminders — the team was like, "we can maybe stop that." Great.

So we were able to take that feedback about the sprint process of what we wanted to start, stop, and continue. And then also, as a team, based on what we're working on — now that we actually have the visibility to see what we are working on — what should we start, stop, or continue doing in our day-to-day and with customers?

Jen That's fantastic, I love that. It sounds like you used that sprint process to iterate on processes in ways that you hadn't before, almost like an after-action report.

Steph Totally. And one of the really cool things that we saw — I mentioned we were releasing a lot of brand new features, brand new parts of our product, or enhancements to features that folks already loved but now were totally leveled up and got a makeover. We wanted to educate customers about those things, and the workshops were a really cool way to do that.

Once we started to do these workshops, we were actually able to track — let's say we had a workshop on a specific part of our product — we were able to track adoption of that feature post-workshop. And we saw just like a hockey stick, that positive upswing that you want to see.

And this was not just for new features that we released, but also for any feature that we did a workshop on. We saw engagement climb after that workshop. And we did the due diligence to look: were there other email marketing campaigns that went out, was there another reason for it? And we were able to safely correlate that the adoption was because of the workshops.

So everyone was thrilled with that. We were thrilled, because we really felt like we were getting time back in our day. Instead of having to meet with six different customers and talk about the same thing, now we have this scalable option where I get on and I plan a workshop and 150 customers come and they learn about it, and then they're actually using it. It was really validating.

But then product leadership was really excited about it, our C-suite was really excited about it. Everyone was just really thrilled about the success of the workshops. And I really don't think that we would have been able to lean into that as much if we hadn't done the exercise of sprints, to at least reflect on what we were spending our time on to identify those trends. I really felt like that was key.

Jen Just curious — were those workshops invitation only for high-value, high-revenue accounts, because they're replacing one-on-one meetings?

Steph The really interesting thing about this was we could still have one-on-one meetings with customers, but we were trying to have them attend the workshop instead, or at least as a precursor to a more strategic conversation. So they weren't meant to replace those one-on-one calls completely, but they were meant to complement them — and also allow us to have our one-on-one calls be a lot more strategic, because they already had the basic understanding of what the feature was and why it mattered to them, and now we could just get to building together in a one-on-one call.

Jen Brilliant. Because you probably felt like you were repeating yourself a lot on these one-on-one calls with folks who didn't know about these basic things.

Steph Totally. And we were like, that's a waste of time. It felt like we were a broken record sometimes. Everyone has their zone of genius, and so how do we allow our team to lean into what we're really good at, and give us some time back in our day-to-day to just spend it where it matters? Workshops allowed that, which helped team morale too.

Our workshops were published — we had an event landing page that was published on our website, so it was not invitation only, any customer could attend. And it was really accessible to see what workshops were coming up right within our platform.

Jen And so then you as a CSM probably pushed that to your customers specifically, even though they were public. You were sort of like, well, we can save a meeting here —

Steph Exactly.

Jen Wouldn't you love to come to this workshop?

Steph Exactly. So I could say, we're actually having a workshop on that in a couple of weeks, register here. We did a lot of that, but they could also self-serve that and see that in our platform.

And then the really cool thing is now we have this library of recordings, so we're still reaping the benefits of a workshop from November or December today, and we can continue to use that for months. Which is huge.

Jen You just send them that link and they can watch on their own time. I love it.

So can you walk me through this template that you shared? It looks like to me the main components are the task itself, the category it's in, the assignee — the person who is either adding it or who owns it — the sprint month, and the size. Oh, and the status. Did I get those? Is that the bones?

Steph That's right, yeah.

Jen Is this a document that you're opening during that monthly meeting and populating together while you look at it?

Steph Totally. I would typically take the lead, especially in the beginning while I was getting the team used to a new thing — I would populate it based on the planning session that we had.

As the team got more comfortable, and I got more buy-in from them, and honestly built some trust around why this would be really helpful if they were able to lean into it, I was able to get my team, before our planning session, to actually come into this template and brain dump their ideas for the upcoming month.

Jen Okay, great. And so then you talk that through, and everyone has access to it, so throughout the month they can add anything that comes up that they didn't predict.

I imagine you would filter by — what were some of the views that were most useful? Filtering by category, or by month?

Steph In the beginning we would just filter by month, so that you only were seeing that month's items. And maybe once we got to month two or three of doing this process, my director decided to add a category field, because she wanted to be able to report out these trends, these buckets of what types of activities are we spending our most time on.

So implementation, versus walking a customer through early access of a feature before it's released with one of our product managers, or planning a workshop. Maybe there's a renewal that's really challenging that we're partnering with the sales team on and we're spending a lot of time building a business case for renewal with a customer.

So my director created these categories to be able to label things and have those trends and insights.

The other thing that I'll mention is status is sort of optional. I felt like it was really important with my team to have a box that said "did it get done, yes or no," because I wanted to be able to check off did we complete it. And I didn't really care as much about the current status.

The reason for that, I think in the world of CS especially, is again — I did not want my team to feel like this was a tracker that they on a daily basis had to come in and update. I didn't want that burden for them. Things generally, with some of our more complex enterprise-level accounts, do take some time to complete. The status could be "in progress" for two months sometimes on some of these items.

So just giving them the ability to use a status if they wanted it, but making it completely optional. If someone wanted to use this as a project planner and a tracker, they have a status — not started, in progress, on hold, or completed — but there was no expectation for them to actually engage with that field. I thought that was really important.

Jen That is important, that it lightens that load, so it's not a big complex process.

And two, it sounds like you didn't keep track of hours spent on each. It sounds like it's the size of the task that was primarily what was used to say, this is how much time we're spending on things.

Steph Totally. As a team we decided what we felt was a small, medium, or large project or task. So we just defined what qualified for each of those buckets essentially.

In agile sprints there's usually some sort of point system that engineering teams use for their tickets. But we decided to just use: we think it's a small, medium, or large item. Small items were something that you can get done in less than an hour. I think we decided mediums were a few hours of your time, large is more than a week, and extra large is a multi-week initiative.

That was just how we broke it down. We didn't want it to be something that we got too hung up on, but just something like a gut feeling. And that's typically what happens in a sprint planning session — you decide as a group what's your gut feeling about the lift that it's going to take to accomplish this.

Jen Backing up a second — how did the webinars come out of this sprint process exactly? Were you looking at the sprint and going, "gosh, we spend a lot of time one-on-one with customers," and then brainstorming how to fix that? Is that how that happened?

Steph Once we started documenting the activities and the types of conversations that we were having with customers, we started to realize that we were talking about a lot of the same things over and over, to a lot of customers of different revenue levels.

Jen So the same amount of time with really large customers and really small customers.

Steph Exactly. And our CS team that I'm talking about, we were only responsible for a certain threshold of revenue. So there's also this whole other cohort of customers that don't have a dedicated person, but are still probably thinking and struggling and wondering the same things. Maybe some of that sentiment was captured by them submitting a case or a ticket, but they weren't really having as many of those one-on-one calls as we were.

So I think we were able to ask ourselves: well, if my customer is struggling with this, and I have 10 customers that are struggling with this — and oh wait, you also have 10 customers that are struggling with this — what other customers do we not know about that aren't speaking up, that maybe don't have a direct person that they can go to and say "hey, I'm struggling with this"?

Jen So working one-on-one with these customers, you identified their pain points, which — people might say tech-touch customers, or customers who are not working one-on-one, must obviously be having those problems. Which is where your role as customer success becomes research about the whole customer body.

Steph Yes. Even going back to when we were doing the in-person meetups, it wasn't just the high-touch or enterprise, whatever you want to call it, customers that were invited. Everyone was invited. So we did see a really wide range of customers who were really engaged, but also didn't know about some of the features that we really wanted them to know about and use.

When we started doing the sprints, my team was only focused on a certain subset of customers. But we had this hunch — huh, if we're seeing this, what about the tech-touch customers? What about that more scalable side? This could affect our entire customer base. We're seeing this and we have this hypothesis just from the customers that we're interacting with. So how can we problem solve and impact all of our customers, no matter the size?

Jen And separate from customers, it sounds like your team got a lot out of this. I'm getting this picture of a team meeting up and collaborating about their siloed work more than they had in the past. That must have felt good — it must just be a felt win.

Steph It was a great win. We had the opportunity to connect more and share more about what we were working on in a really productive way. We could talk about what we were working on, we could share ideas with each other, and then we could actually take action on those ideas. That really feels like the most rewarding thing.

Jen Not quantifiable, but really important.

Steph Totally. And then the bonus, out of all that feel-good stuff for my own team, was the impact on the customers. That's why we're in these roles — we want to impact our customers.

So it was just really cool to see that we identified trends, we experimented with new ways to touch customers and meet them where they were at — through workshops, through help center articles, through other self-service one-to-many offerings, which we're still continuing to evolve to this day. But seeing our customers' adoption increase as we started to layer in these different self-service scalable activities, from the work that we had done in the sprints to analyze that, was just great for the business and great for everyone involved honestly.

Jen So satisfying. Those customer engagement numbers when they go up, it's just like a party.

That's fantastic. I love this. I think it's going to be really useful to customer success, customer support, any CX team that wants to get closer to each other's work and identify ways to improve. You didn't know before you started the sprint process that webinars were going to be a solution that came out of it, right?

Steph Exactly. I think if we just take a pause and really take a step back and reflect on how we're spending our time, we can remove ourselves from the hamster wheel — which is something that I think we get really caught in as customer-facing folks. A customer needs something, we're on it. That's always going to be the case and that's never going to stop. But how can we actually take a pause and be a bit more strategic and identify ways to make the customer experience better, and ways to reduce burnout and feel good as a customer solutions team?

Jen Your team is lucky to have you, I love it. And we are lucky to have this process that you developed. I can't wait to share the template and everything. So thank you so much for being here.

All right, let's recap quickly. Steph took us through how she brought agile sprints into CX to create more focus, efficiency, and impact.

Step one: be passionately curious. Now, full disclosure, I added this step, because I just observed that Steph was exploring ideas outside of her role, which helped her connect the dots between a common CX challenge and a solution from an unexpected place.

Step two: pitch the idea at the right time. When leadership raises concerns, if you already have a solution in mind, you can frame it in a way that naturally aligns with your team's goals.

Step three: draft the why and the how. Steph clearly defined the purpose of sprints, setting expectations for how they'd create more focus and reduce inefficiencies.

Step four: adapt the sprint framework for CX. Instead of following a rigid engineering approach, Steph structured sprints around customer education, feature adoption, and reducing redundant one-on-one meetings. This allowed the team to focus on proactive, high-impact work instead of reacting to the same questions repeatedly.

Step five: share and get buy-in. She published the framework internally and introduced it in a way that made it easy for the team to engage, instead of over-engineering.

Step six: trial and iterate. She kicked off a trial sprint, gathered feedback, and made improvements along the way.

The result was a structured, scalable way to align CX efforts that Steph's whole team is still using.

If you want to make your support or success team more proactive, try Steph's idea. Take a page from her playbook and start experimenting. Thanks for listening, and we'll see you next time on Live Chat with Jen Weaver.