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.

Advertisements

You’ve got to have SOME standards

Well-defined, agreed upon standards are key to successful development using scrum. When you convert from waterfall to an iterative process, standards replace a lot of the requirements that you historically included in your specifications. They also govern team processes and at a more micro-level than the scrum broad rules do.

At Streamline Health, when we form a scrum team, their first sprint is a “Sprint 0” during which they form their standards. As a group they determine what their definition of done should be, including what specific standards each item they produce must adhere to.

It’s not a wide open field. We have some best practices and some required processes in place that apply to all of our scrum teams, and some even apply to our dev ops teams. For example, manual testing must use our testing tools and maintain traceability between defects and requirements. Teams must show test metrics during the sprint demo. Our management tool, Microsoft Team Foundation Server, is configured with standard queries for all teams and products so that anyone can understand what’s in the backlogs for all of our products. Teams do not have the leeway to change these.

More technical standards do vary from team to team and product to product depending on the age of the code, the predominant language, and even whether it’s web based or thick client, SaaS or premise installed. Unit test code coverage, test automation, coding standards for architecture and design, code commenting, source code structure, and database structure can all vary among our teams.

Quality of Service standards, what you may think of as non-functional requirements, are a mix of enterprise-wide and product-specific (e.g., branding is enterprise wide, but other GUI requirements are specific to the product).

In a recent lunch and learn, members of all of our scrum teams came together to discuss the state of their teams’ standards:

  • When did they last review them?
  • Do new members have to read them before getting to work?
  • Does everyone know where to find them?

The result of this frank, honest discussion was an agreement for teams to review their standards early and often, use the sprint retrospective cadence as an organic milestone to refine standards and reinstate a neglected process of “retrospective of retrospectives” wherein the scrum masters come together to share global improvement opportunities – including scheduling review of standards in the next HIP sprint.

— Luis Lira, Manager of Business Analysis

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