BI-Driven Development: Testing Outcomes Rather Than Outputs

In my book The Art of Business Value, I – almost jokingly – tossed out the term BI-driven development (BiDD). This was a play on the idea of Test Driven Development (TDD), where developers first write automated tests for their code, and only then write the code itself. We use BI, or Business Intelligence systems, to report on business metrics. My proposal was that we first decide how to measure the results we want our new features or systems to achieve, build a way of measuring those results – probably in the company’s BI system, and then start developing those new features. Since the book came out, a number of people have expressed interest in the idea, so I wanted to explain a little further what I have in mind and why it is important to our practice.

Historically, IT projects have been based on a set of requirements – essentially instructions on what should be built. With the introduction of Agile development approaches, we began to view these requirements as things that could be juggled, added to, or subtracted from. But this misses the real point of the Agile approach. The Agile idea is to deliver business value – outcomes – rather than particular features. In a sense, the requirements are not just flexible, but almost irrelevant. Any set of requirements that generates the desired business outcomes (at a high level of quality and a low cost) is just as good as any other set of requirements. Autonomous teams are truly autonomous when we charge them with delivering outcomes, rather than charging them with delivering a particular set of user stories or requirements.

In many formulations of Agile, teams are charged with delivering product that meets the needs established by users and a product owner – that is, they are charged with delivering outputs. But with DevOps – where the team is responsible for a much broader subset of the value stream – and takes feedback from their code’s performance in production to improve the product – we can give them responsibility instead for outcomes. Test-driven development measures outputs – does the code I wrote do what I was told it needs to do? BiDD is intended to measure outcomes. The “requirement” that flows to the team is to improve a business metric; the test of whether the team has done so is created through a BI dashboard that measures that metric; and the team’s progress and success can be measured by watching that dashboard over time. Arguably, the so-called “requirements” don’t matter – the team determines its own requirements with the goal of achieving the business’s desired outcome. Now that is autonomy!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s