Calibrating Business Value

When you’ve got five software products managed by five product managers, how do you know that they’re all using the same scale when they assign business value?

You don’t. At least, not if you don’t pay some attention to calibrating across the organization.

The other day we had a lively discussion as we looked at completed user stories from our various backlogs and the business values that they’d been assigned. Participants included not only the folks in backlog management roles (directors, managers, and business analysts), but also scrum team members and folks from sales, IT, and client services. It was a fantastic opportunity to show these non-development team members that engineers do want to deliver value!

Nobody in the room knew all about all of the products. But once we’d presented the fundamentals of how business value is used in scrum and a way to evaluate a story, most everyone reached similar values on stories that they understood. We explained our existing scale (zero to three hundred points in ten point increments), and then we suggested some criteria:

  • What percentage of existing clients want it?
  • Is it for the primary user persona?
  • Has it been validated through customer development?
  • Is it sizzle or steak?
    • Is it primarily to help sales close deals?
    • Is it a technical change that will retain existing clients?

Then we presented a series of examples and asked the group to assign value (see the image above). For some, consideration of the number of impacted users was a revelation. For others, abstracting business value by not somehow tying it to revenue was pointless. And for a few, accepting that solving our own problems, like improving deployment or fixing the logo on the home page, has no business value was really tough to swallow. Nonetheless, everyone left with a clear understanding of what those numbers mean on our work items, and the product management team is going to do better at calibrating their value assignments with their colleagues’. That’s a win.


Streamline Health’s Lifecycle Practices

Streamline Health develops software solutions that support revenue cycle optimization for healthcare enterprises. Streamline’s Innovations department is responsible for creating and maintaining our software products, from requirements gathering through to delivery of releasable code to our client services team. This blog is presented by members of the Innovations team to share our application lifecycle best practices, challenges, and the insights we gain as we grow.

In January, 2015 we implemented the Scaled Agile Framework to manage our five separate software products and development teams. This included formal scrum training for all of our development team members, whether or not they were already “doing” scrum. SAFe helped us to normalize our release planning and code delivery schedule by synchronizing our scrum teams’ iteration cycle. At the enterprise level, SAFe helped us bring diverse development efforts into focus so that resources could be better aligned with corporate objectives. Since that launch we have continued to refine our practices and process.

In 2017, we’re kicking off ongoing ALM training. Our goals are to refresh people across our organization about our best practices, to bring new team members up to speed, and to engage with everyone in the continuous improvement process. Follow along with us as we teach, learn, and improve.

— Mia McCroskey, Director, Solution Lifecycle Management