SAFe Metrics at the Team Level: Sales Ops

Contextualizing SAFe metrics: sales ops edition

SAFe® provides the strategic concepts and guidance that help steer transformations. And while the Framework metrics article focuses on high-level metrics like KPIs, OKRs, and strategic themes, some teams can struggle to contextualize SAFe metrics and measurement domains like flow, outcomes, and competency.

This is especially true for non-technical teams.

Even when metrics are captured, improvement areas might remain blurry without a shared understanding of what the metrics mean and show.

Diagram of metrics at the portfolio, Solution, ART, and team levels

How do teams with different skill sets, business objectives, and types of work all use the same measurement domains to gauge success? How do they know if they are on track to achieve PI Objectives and Iteration Goals?

We asked Scrum Masters from five different teams to answer five questions about the metrics they use to measure flow, outcomes, and competency. Their answers were illuminating, and we’re excited to share the results in a new article series titled “SAFe Metrics for Teams.” Each article will highlight one or more teams and take a close look at how they use SAFe metrics in their own domains.

TEAMS SURVEYED

  • Sales Ops
  • Communications
  • Multimedia
  • Customer Success
  • Product Development

METRICS SURVEY QUESTIONS

  • What metrics does your team use to track outcomes?
  • How do these metrics help your team define and plan work?
  • What flow metrics does your team use?
  • How has your team used metrics to drive continuous improvement?
  • How does your team self-assess competency?

Let’s get started!

Applying SAFe® Metrics for a Sales Operations Team

Sales ops teams are charged with enabling the sales team to hit their growth targets. This means sales ops should do work that creates a better, faster, and more predictable sales process, including:

  • Lead management and routing
  • Database integrity
  • Enablement training
  • Sales team onboarding
  • Continued learning and development
  • Contract management solutions
  • Sales process optimization
  • Much more  

By nature, sales ops work is often routine and process-heavy. It’s a lot of “run the business” or “business as usual” (BAU) work. Despite its sometimes repetitive nature, the pace and volume of this work will affect sales team objectives. Agile marketing teams are often in a similar position. 

Plus, enterprise-level sales are getting more complicated. There’s more technology, data, tools, and systems than ever. For sales leaders, this complexity means spending more time managing systems and less time working with teams and growing territories. As sales teams face increasing pressure to become more customer-centric and responsive, the demand for Agility also grows.

How can sales ops teams embrace the same Agile spirit and practice that drives other business areas like development and IT? More specifically, how can a sales ops department employ measurements like flow, outcomes, and competency in the same way as other SAFe teams?

For Kate Quigly, a senior Scrum Master with the sales ops team, it starts with the right mindset and clear goals focused on helping sales teams embrace Agility in their planning and operations. We asked Kate to lift the lid on her team’s process for using metrics, pursuing improvement, and applying SAFe measurement domains. Below, Kate explains how the sales ops team makes SAFe guidance work for them.

OUTCOMES

Question: What metrics does your team use to track outcomes? How do these metrics help your team define and plan work?

Answer: Outcomes are the perfect opportunity to assess which work is worth doing and what value is delivered. Here are the metrics we use to measure outcomes:

PI Objectives

The nature of our work makes it fairly simple to craft SMART PI objectives. Here’s an example of a good PI objective for a typical sales ops team:

  • Example: “To grow strategic accounts by five percent in Q1 2023, create three account plans per region, and complete five live training sessions with sales by the end of Q4 2022.”

This objective would align with our team’s mission to bolster the sales team’s performance and operations in several ways:

  1. It empowers sales to develop their account plans in the future. With this capability, sales can immediately take action to capture new opportunities in expanding regions.
  2. It’s written to help sales achieve growth targets, which could be a strategic theme and/or PI Objective for the entire ART.
  3. It enables future work that will contribute clear business value.

Team Business Value

Business value assignments are where we learn whether the right work was planned and completed correctly. We can use business value scores to understand the following:

  • Did we plan the right mix of work? For us, this could mean uncovering the wrong balance of BAU work vs. “user-facing” projects.
  • Were we able to complete our committed objectives? If not, why?
  • Were our objectives clear and measurable?
  • Are we delivering value?  

Iteration Goals

Iteration goals keep us focused on the most important work. Because iteration goals are not always reflected in a single story, we can check each iteration to see if visible work is actually contributing to our iteration goals (and PI Objectives). We want to discover if completed stories actually support the iteration goals. If there’s misalignment here, and we’re planning proper capacity, trouble could be around the corner.

Team Purpose Statement

While objective metrics are critical, qualitative assessments also matter. We often refer to our team purpose statement to check whether planned work needs to be rephrased, reexamined, or re-scoped to align with our core purpose.

FLOW

Question: What flow metrics does your team use?

Answer: Since we’re a relatively new team, we’re still honing the best set of metrics. I recommend using a variety of metrics as each one can highlight valuable insights. Right now, we use the following metrics most often:

Flow Velocity

  • Team velocity should be a stable, predictable measurement that helps the team forecast capacity for future work. Velocity metrics should never be compared across teams or used as a productivity measurement. Too much emphasis on achieving the right number can cause teams to “game” the system.  
  • I use some standard questions to spark conversations, including: 
    • Is our team velocity significantly dropping? Let’s discuss why.
    • Is our team velocity significantly increasing?  What’s the cause of this increase?
  • In particular, we look at the number of rollover stories from one iteration to the next. The root cause of these rollover stories can reveal issues with prioritization, role competency, and dependencies. This analysis helped our team discover a missing toolset needed for data management work.

Flow Time

We use cycle time scatterplot charts to show lead time and cycle time. These charts capture when an item starts and finishes. Low cycle time means the team is performing well and value flows fast to customers. Items with high cycle time are easy to identify and retrospect on.

Measuring flow time helped us find a recurring delay within the legal department. The delay caused an issue with generating new contracts, which are critical for our internal customers (sales) to finalize their work within a fixed timeline. 

This data helps us talk about problems in a new way by asking the following:

  1. Why did some items take so long to complete? What could we have done differently? Are there action items we can do to improve?
  2. Our average time to finish an item is X amount of days. What improvements would lower this for even more efficiency? 

Flow Distribution

Distribution is crucial for understanding whether we’re spending time on the right mix of work types. The team believes (rightly) that BAU work should be shown and recognized. Common BAU work includes:

  • Analyze closed lost/won deals
  • Data cleanup
  • Contract updates
  • Onboarding/offboarding tasks
  • Training, onboarding, and enablement 

However, I’ve had to coach the team on how to incorporate this type of work into Scrum, and how to balance BAU with “new development” work, which we affectionately call “special projects.” For our team, special projects would include work like:

  • Salesforce automations
  • New system implementation for key account management

For us, all of these metrics roll up into two primary dashboards. We frequently use the following charts to check our progress:

screenshot of an iteration cumulative flow diagram
Iteration cumulative flow diagram
screenshot of a release flow diagram
Release cumulative flow diagram
Burndown chart
  • Iteration and Release cumulative flow diagrams help visualize the work. These diagrams show cycle time, work in progress, and throughput.
  • This metric surfaced an interesting “stair step” pattern, which could indicate rushing at the end of the iteration. Once identified, we were able to find some key bottlenecks that are unique to the sales environment.
  • Burndown charts. These charts can predict the team’s likelihood of completing the committed work in a given time period. By visualizing the work in this way, you can see if delivery is on track, will complete early, or will be delayed.

Question: How has your team used metrics to drive continuous improvement?

Answer: These metrics help us identify mistakes, whether it’s a missed dependency, unclear acceptance criteria, or errant planning. For example, I’ve seen our team continually battle context switching, indicated by a large amount of work in progress (WIP). 

The context switching was causing us to miss more meaningful opportunities. For sales ops, this could mean putting new dashboards on hold and instead prioritizing new account research. During team retros, we can use questions like the following to identify improvement areas: 

  • Are there too many items “in progress” which can result in costly context switching?  
  • Are there too many items “in progress” which can signal a bottleneck problem in our workflow?
  • Is there a large amount of work that is “not started” that may cause us to delay or miss upcoming milestones?

Improvements tested:

  • Stop starting and start finishing by limiting WIP
  • Swarming or pairing to complete work faster 

Teams identify and embrace metrics depending on how you set the stage and approach these conversations. Again, for us, the priorities are clarified by focusing on the most valuable work instead of giving all planned work the same priority level. We must continually ask: “what’s the most value we can deliver this week, this iteration, and this PI?”

COMPETENCY

Question: How does your team self-assess competency?

Answer: As a new team, we’re focused on the team and technical agility assessment, which was just distributed to the team. I am very excited to use this as another tool to start team conversations about improvement areas.

Bonus Tips

Kate shared a few other key ways that sales ops teams can “think” Agile and adapt SAFe practices to their business domain:

  • Will the planned work allow sales team members to be more decentralized, productive, and empowered in their job?
  • Is the planned work only planned because “that’s the work we do”? 
  • What work would support cross-functional capabilities for sales teams/members?
    1. Example: A standardized sales deck with editable fields to eliminate dependence on graphic design support.
  • What processes can be automated to create economies of scale?
    1. Example: An automated, repeatable de-duplication process for faster and more accurate CRM data management.   

Overall, changing their way of thinking about work and measuring value has helped the sales ops team embrace Agile principles and improve alignment across the ART. As a result, they have better tools for visualizing, categorizing, and prioritizing BAU work with critical projects while also seeing the real value they deliver.

About Kate Quigly

Kate is a Senior Scrum Master at Scaled Agile, Inc. She has many years of experience coaching Agile teams with high energy and creativity.  She is passionate about lifelong learning, experimenting with teams, and creating a collaborative culture. Connect with Kate on LinkedIn.

About Madi Fisher

Madi is an Agile Coach at Scaled Agile. She has many years of experience coaching Agile teams in all phases of their journeys. She is a collaborative facilitator and trainer and leads with joy and humor to drive actionable outcomes. She is a true galvanizer! Connect with Madi on LinkedIn.

Connecting OKRs, KPIs, OVSs, and DVSs – For Successful SAFe® Implementation

The title of my post may read like acronym soup but all of these concepts play a critical role in SAFe, and understanding how they’re connected is important for successful SAFe implementation. After exploring some connections, I will suggest some actions you can take while designing, evaluating, or accelerating your implementation.

KPIs and OKRs

The SAFe Value Stream KPIs article describes Key Performance Indicators (KPIs) as “the quantifiable measures used to evaluate how a value stream is performing against its forecasted business outcomes.

That includes:

  • Health of day-to-day performance
  • Work to create sustainable change in performance

Objectives and Key Results (OKRs) are meant to be about driving and evaluating change rather than maintaining the status quo. Therefore, they are a special kind of KPI. Objectives point towards the desired state. Key results measure progress towards that desired state. 

But how do these different concepts map to SAFe’s Operational Value Streams (OVSs) and Development Value Streams (DVSs)? And why should you care?

Changing and Improving the Operation

Like Strategic Themes, most OKRs point to the desired change in business performance. These OKRs would be the ones that company leadership cares about. And they would be advanced through the efforts of a DVS (or multiple ones). 

For example, if the business wants to move to a subscription/SaaS model, that’s a change in the operating model—a change in how the OVS looks and operates. That change is supported by the development of new systems and capabilities, which is work that will be accomplished by a DVS (or multiple ones). 

This view enables us to recognize the wider application of the DVS concept that we talk about in SAFe 5. Business agility means using Agile and SAFe constructs to develop any sort of changing the business needs, regardless of whether that change includes IT or technology.

Whenever we are trying to change our operation, there’s a question about how much variability we’re expecting around this change. Is there more known than the unknown? Or vice versa? Are we making this change in an environment of volatility, uncertainty, complexity, and ambiguity? If yes, then using a DVS construct that employs empiricism to seek the right answers to how to achieve the OKR is essential, regardless of how much IT or technology is involved. We might have an OKR that requires business change involving mainly legal, marketing, procurement, HR, and so on, that would still benefit from an Agile and SAFe DVS approach.

These OKRs would then find themselves elaborated and advanced through the backlogs and backlog items in the various ARTs and teams involved in this OKR. 

In some cases, an OKR would drive the creation of a focused DVS. This is the culmination of the Organize around Value Lean-Agile SAFe Principle. This is why Strategic Themes and OKRs should be an important consideration when trying to identify value streams and ARTs (in the Value Stream and ART identification workshop). And a significant new theme/OKR should trigger some rethinking of whether the current DVS network is optimally organized to support the new value creation goals set by the organization.

Maintaining the Health of the Operation

As mentioned earlier, maintaining the health of the operation is also tracked through KPIs. Here we expect stability and predictability in performance. It’s crucial work but it’s not what OKRs or Strategic Themes are about. 

This work can be simple, complex, or even chaotic depending on the domain. The desire of any organization is to bring its operation under as much control as possible and minimize variability as it makes sense in the business domain. What this means is that in many cases, we don’t need Agile and empiricism in order to actually run the operation. Lean and flow techniques can still be useful to create sustainable, healthy flow (see more in the Organizational Agility competency). 

Whenever people working in the OVS switch to improving the OVS (or in other words working on versus in the operation), they are, in essence, moving over implicitly to a DVS. 

Some organizations make this duality explicit by creating a DVS that involves a combination of people who spend some of their time in the OVS and some of their time working on it together with people who are focused on working on the OVS. For example, an orthopedic clinic network in New England created a DVS comprising clinicians, doctors, PAs, and billing managers (that work the majority of their time in the OVS) together with IT professionals. Major improvements to the OVS happen in this DVS.

Improving the Development Value Stream

The DVS needs to relentlessly improve and learn as well. Examples of OKRs in this space could be: improving time-to-market, as measured by improved flow time or by improving the predictability of business value delivered, as measured by improved flow predictability. It could also be: organize around value, measured by the number of dependencies and the reduction in the number of Solution Trains required. 

This is also where the SAFe transformation or Agile journey lives. There are ways to improve DVSs or the overall network of DVSs, creating a much-improved business capability to enhance its operation and advance business OKRs. 

Implementing OKRs in this space relates more to enablers in the SAFe backlogs than to features or capabilities. Again, these OKRs change the way the DVS works.

Running the Development Value Stream

Similar metrics can be used as KPIs that help maintain the health of the DVS on an ongoing basis. For example, if technical debt is currently under control, a KPI monitoring it might suffice and hopefully will help avoid a major technical debt crisis. If we weren’t diligent enough to avoid the crisis, an objective could be put in place to significantly reduce the amount of technical debt. Achieving a certain threshold for a tech debt KPI could serve as a key result (KR) for this objective. Once it’s achieved, we might leave the tech debt KPI in place to maintain health. 

It’s like continuing to monitor your weight after you’ve gone on a serious diet. During the diet, you have an objective of achieving a healthy weight with a KR tracking BMI and aiming to get below 25. After achieving your objective, you continue to track your BMI as a KPI.

Taking Action to Advance Your Implementation Using OKRs

In this blog post, we explored the relationship between operational and development value streams and the Strategic Themes and OKRs. We’ve seen OVS KPIs and OKRs as well as DVS OKRs and KPIs. 

A key step in accelerating business agility is to continually assess whether you’re optimally organized around value. OKRs can provide a very useful lens to use for this assessment. 

Start by reviewing your OKRs and KPIs and categorize them according to OVS/DVS/Change/Run.

You can use the matrix below.

Run-focused OKRs

If you find some OKRs on the left side of the matrix, it’s time to rethink. 

Run-focused OKRs should actually be described as KPIs. Discuss the difference and whether you’re actually looking for meaningful change to these KPIs (in which case it really can be an OKR—but make sure it is well described as one) or are happy to just maintain a healthy status quo. 

You can then consider your DVS network/ART/team topology. Is it sufficiently aligned with your OKRs/KPIs? Are there interesting opportunities to reorganize around value?

This process can also be used in a Value Stream Identification workshop for the initial design of the implementation or whenever you want to inspect and adapt it.

Find me on LinkedIn to learn more about making these connections in your SAFe context via an OKR workshop.

About Yuval Yeret

Yuval is a SAFe Fellow and the head of AgileSparks

Yuval is a SAFe Fellow and the head of AgileSparks (a Scaled Agile Partner) in the United States where he leads enterprise-level Agile implementations. He’s also the steward of The AgileSparks Way and the firm’s SAFe, Flow/Kanban, and Agile Marketing. Find Yuval on LinkedIn.

Share:

Back to: All Blog Posts

Next: Aligning Global Teams Through Agile Program Management: A Case Study