Value-Driven Planning Turns Dev from Cost Center to Value Driver

Value-driven planning. Value stream management. Value stream mapping. These topics have become buzzwords as of late - but what do they really mean? Is there any real value to these practices? And not to mention, are they even different from one another?!

Yes - and in more ways than one!

We’ve spent some time covering value stream management and how value stream mapping can lead to increased ROI as you make data driven decisions regarding your development lifecycle. Value-driven planning adds another very tactical layer to this equation. Rather than analyzing development data to optimize the flow of value to the customer, as value stream management does, value-driven planning should serve as the basis for what work is in development in the first place.

The Problem with Traditional Planning Methods

“But I already plan my sprints based on what the most valuable work of the moment is!” Scrum Masters from every corner scream.

While it may feel that way, common planning constructs are typically influenced by many factors other than value, no matter what development framework you use. I have worked with engineering teams that have followed Scrum, Agile, Kanban, Project-based, Shape Up, and other random combinations of these frameworks over the last 10 years. Some of the prioritization methods I’ve personally seen (whether intentional or not!) include:

• Top down: When the CEO (or other exec leader) has a vision for the company, they may want a say or a vote in what dev teams work on - what they think will put the company ahead in the market, address competitor pressure, appease the board, or position the company well from any other lens they care about. This is more likely to happen at smaller companies or startups where there aren’t as many “layers,” but this type of prioritization runs the risk of having devs continually work on things that are reactive to the market, too visionary for customers’ current needs, or ignore the most effective flow of work.
• Developer-led: In my experience, developers like to work on interesting problems, problem-solve until they find the best solution, and improve the system where they can. All of these things are wonderful. However, if left to their own devices, developer-led initiatives and interests may not align with product strategy, customer requests, or work that would move the company forward in a measurable way.
• Backlog drive: Oh, the infamous backlog. It can become a deep, dark hole of half-baked ideas, piecemeal work, and forgotten initiatives. If not well-groomed, backlog-driven prioritization can take development off the rails, fast. Not only is the sheer length of tasks overwhelming at times, but when user stories for different capabilities and projects are intermingled, moving any one larger body of work can become difficult as builds stretch out over multiple sprints.
• User feedback: User feedback is a huge component of understanding what capabilities and improvements add value to a business. However, that feedback must be vetted and considered as part of the larger company strategy. Does it advance the product or supported process in the right direction? Is there a better way to solve the users’ problem?
• Time available: In one of the most interesting ways to prioritize work, the “time available” method basically says “we have x amount of developers / developer time left in this period, based on what we’ve already planned - what else can we fit in?” Ideally, some margin would be left in the sprint to dedicate to bugs or tech debt, but I have seen more than a few instances of feature work partitioned out in this way.

Clearly, everyone has a different opinion of what work should be prioritized and when. So how can teams ensure they’re working on the most valuable thing, when value has a different definition for almost every stakeholder?

Value, Defined.

If your company’s aim is to increase the amount the company is worth - and I’m not aware of any company that ISN’T looking to do this - avenues of increasing value must first be defined.

Two of the most common value creators include productivity gained (i.e. improving apps for internal users, so how they do their work is more streamlined, automated, or efficient) and product revenue (i.e. building capabilities for external customers in a way that improves sales, stickiness, and user adoption). The former leads to value creation through employee time savings, while the latter leads to cash flow for the business.

No matter which route applies to you, the value of each piece of work can and should be quantified. When dollars and cents are applied, prioritization becomes smooth sailing, as it is clear which stories, capabilities, and apps will truly drive value creation for the business.

How to Plan with Copado

This all may sound great in theory, but how can you tactically bring this practice to your DevOps planning rhythms?

We’re all familiar with the user story. Whether you use Copado Plan as your preferred planning tool, or simply integrate ALM systems like Jira and Azure with Copado to gain end-to-end visibility, user stories drive builds. They are the units of change that when packaged and released, create new capabilities and apps. Grouping user stories into capabilities and apps is crucial for focused development and value-driven prioritization, as business value is assigned and tracked at the capability (or feature) level.

In Copado, the user story is the container of change. This means that each and every action taken on a user story, and the metadata it interacts with, is tracked as part of the story’s history. The traceability the user story provides is extremely valuable as work moves through the development lifecycle, because as different people interact with the story, they are able to see any relevant details they may need to help progress the story to the next stage.Stories can be organized, prioritized, and managed from one of the many management options available in Copado - the sprint wall, kanban boards, or work manager. Whereas the sprint wall allows you to break stories down into tasks, assign development hours, change statuses and drag and drop tasks in swim lanes to indicate what stage a story is in, work manager allows you to create custom panels to display a set of user stories based off any field filter that is important to you. Regardless of which feature - or set of features - you choose to use, they are all mechanisms to manage your user stories and drive your sprint forward.

Because Copado is Salesforce native, you have the ability to customize user stories so they are relevant to the way your business operates. With custom metrics, you are able to assign “business value” to features, and thus, prioritize your backlog to plan future sprints based on what will create the most value and impact for the business.

From Cost Center to Value Driver

Organizing work by greatest business value is just the first step of value-driven planning, though. It is crucial that you also monitor and analyze the flow of value to end users. This is best done through value stream mapping.

With Value Stream Maps, you explicitly define all the stages a user story must flow through in order to ultimately get released to production and in the hands of users. Each stage (and each process block within each stage) displays performance metrics that illustrate things like how long a story sits idle before it’s worked on, how many resources are dedicated to the stage, the queue of stories waiting to be worked on before moving forward, and average value of the work in the stage. 

This type of end-to-end visibility into bottlenecks, resource constraints, and inefficiencies gives you the data and insight you need to strategically implement improvements in your development processes. Value stream maps make it clear where value is held up in the development lifecycle, and when dollar amounts are associated to things like wait time, it gets the attention of stakeholders. The visibility value stream mapping brings to business value is one way you can begin to transition development from a cost center to a value driver and prove that applying more resources to one area or another will ultimately benefit the business.  

What’s really exciting is that in addition to showing the estimated value of work to be delivered, ROI of the work can actually be proven over time. For example, if improvements were delivered to help internal users more efficiently address open customer support cases, tracking declines in case service time can help quantify internal time savings for all customer support representatives. Alternatively, if new capabilities were delivered to customers, tracking increases in actual sales of the product that includes the capabilities can help quantify value in terms of revenue. Because all of this data is all in Salesforce (from case resolution time to product sales), it is possible - and extremely valuable - to begin making connections between work delivered and value realized.

Ultimately, the biggest benefit of value-driven planning is not only that the business will deliver valuable improvements to users faster. Rather, value-driven planning gives development teams the power to ensure the most valuable stories, capabilities, and apps are prioritized, prove the ROI of that work, and reframe dev from a cost center into a strategic value driver. And that’s a win all around, isn’t it?