An Agile Business Analysis and Project Management Practice

An Agile Approach to Business Justification

Date Created: 24 July 2014
Date Updated: 30 January 2018

A requirement is a usable representation of a
                        need.  Requirements focus on understanding what kind of
                        value could be delivered if a requirement is fulfilled.
                        The nature of the representation may be a document (or
                        set of documents), but can vary widely depending on the

(Source: BABOK 3, IIBA)

It's the first role of the traditional business analyst: gather requirements. For the big-bang project, all the requirements are gathered at once over a period of months or years; and then, everything is developed at once. In the agile world, requirements are stories, but they still fit the traditional definition: a focus on what kind of value can be delivered if a requirement is fulfilled.

The problem then is, given the traditional methodology, how does it fare in the new agile world? There is a new, somewhat "squishy" term, "story" which took me awhile to get used to. I say squishy because a "requirement" could be functional or non-functional. In the agile world, while the goal is to deliver something functional in every sprint, there is also the concept of the non-functional story, which I think of as foundational. Before we can begin the pyramid, the forest must be cleared and the foundation laid, and yet, the business wants to see a pyramid or at least part of a pyramid.

And, then there is the problem of developer enthusiasm. Wanting to please their customer, the developer may be tempted to deliver something functional without addressing the nonfunctional requirements: performance, stability, refactoring, security, extensibility, maintainability, etceteras. The more "mature" your Software Development Lifecycle (or SDLC), the more etcetras you will have. To me it seems like it would almost make sense to assign each to a different team, e.g., an assembly line, but the practice today is for one team to do it all, unless there are the resources to assign multiple teams to one functional area.

But those problems really belong to the developers and architects. What about the person who is talking to the customer? What about the customer? How exactly do we justify all the money going into the effort?

Value and ROI

ROI or return-on-investment is the value that the business (or customer) expects to derive from the effort. So the value is compared to the cost of the effort and I can immediately sense a ratio: if the value of the thing is $100,000 a year for the next 5 years, and the cost is $100,000, I can see an ROI of 500%. Now if you've been to business school, yes, you can whip out an HP calculator and do a time-value calculation that would actually put that at somewhere between 400 and 500% due to inflation, interest and other factors, but this article is not really about those kind of details. And here's why.

Typically the ROI of a set of proposed improvements will vary quite a bit and in addition to this, they will have intangible value, such as how well they align with strategy, to what extent they are foundational, how they mitigate risk, etc. So ROI is really just part of the value equation, the sales lift or cost savings directly attributable to the opportunity.

Strategic value can really outweigh direct ROI. For example, Bill Gates may have spent $70,000 on building MS-DOS to the point where IBM was willing to accept his license terms to bundle it on the first IBM PC's. But, the dynasty that followed was probably more attributable to Bill's dad's law firm that wrote the license terms, because it locked in a sustainable revenue stream that continues today.

When Can I Measure the Value of an Innovation?

Event Audience Description
Prior to a Major Development Effort Senior Management, Internal Customers ("The Business") Before undertaking a major development, purchasing and installing a new application, etc., it is traditional to do a high level cost/benefit analysis. While business goals are certainly welcome in this context, specific functional requirements have to be left for later in order to enable agility throughout the effort.
Before Undertaking a Feature/Function Enhancement that Requires More than One Day of Development Team Effort (an "Epic") Development Team, Operations Team, Internal Customers A single developer can cost $50 – $2500 a day depending on whether you are working in Bangalore or at Facebook HQ. It behooves your managerial discpline to perform a mini ROI analysis prior to each major undertaking.
Any Requirement Development Team

It really helps when I can be very clear about the following on a very granular level:

  • Who uses it? Who benefits from it?
  • How will we know if it is done, working right, etc.?
  • How fast does it need to be?
  • Does it require security, compliance, etc: what vendors and what other teams need to be involved?
After a Major Development Effort Senior Management, Operations Team, Internal Customers After undertaking a major development, can it be shown that the expected benefits were realized? This has been very important to improve the strength of my processes. For example, when building a system, I determine metrics to help answer this question and then partner with the business to track these throughout the operational lifetime of the system.

The Business Impact Statement

One tool that I have found helpful is to write a concise, one-sentence business impact statement for every requirement. (We used to write them for problem and incident reports in my operations past, so why not write them for requirements?) A business impact statement very simply explains the business functionality or value that stands to be gained if the requirement is achieved, lost if it is not. Here are some examples of these that I have written for a workstation cloud virutalization project:

  • For a class that supports testing the AWS Cloud:

    Minimizes exposure of test credentials by temporarily creating a set of test credentials and then deactivating it immediately after it is used.

  • For a component that performs detailed logging across an entire application:

    A logging function increases the maintainability and reach of unit testing allows more functions to be reached by testing. This avoids making things less secure to provide access to test tools.

    Logging reduces future costs in these areas:

    • Component reuse within java applications.

    • Qualification of new environments.

    • Changes to security, account permissions, etc.

    • Changes to configuration of user computers.

    • Changes to global configuration such as cloud, region, security.

    • Logging information can be captured from monitoring agents in response to production incidents.

    • Logging information can be captured from the automated deployment of any of the above.

  • For a Java component that takes snapshots of machine images for a point-in-time restore capability:

    Amazon machine images (AMIs) can be used to save money while a system is not required, by storing a system configuration and a system's magnetic hard disks in inexpensive cloud storage.

Note that while the langauge above references some computer terminology, it also provides a clear picture of the business impact, e.g. WHY we are building it. Sure, some business eyes may glaze over, but in my experience the leaders who are making a difference are eager to consume and grasp information like this.

A Business Case for my Site-Test Project

benefit of automated testing

  • saves 10%-50% developer time. developers get work done faster.
  • allows bugs to be found more quickly, thus reducing business impact.
  • increases the velocity of development.
  • more comprehensive than manual testing; run full regression every time
  • supports rapid integration testing and operations tests, useful for doing rapid deployments

benefit of this tool specifically

  • creates generic platform for building tests that can test just about anything
  • allows site to be tested automatically, before and after changes, and periodically
  • safely manages credentials, excluding them from shared storage
  • uses java, "lingua franca" of corporate IT

It's helpful to document it when alternatives have been considered.

three alternatives

  1. Use Selenium IDE. Although this tool makes it easy to record and play back user clicking and typing, it lacks the support of a full development language. This makers of this 1.0 version product recommend using the 2.0 version for this and other reasons.
  2. Use javascript instead of java. The term "libraries" refers to pre-built components that can be plugged into an application to avoid reinventing the wheel. Although javascript has gained in popularity it does not have quite the same library support as Java; more components might need to be developed.
  3. Test manually with user scripts and checklists. This is how we currently do things. It is error-prone and in many cases problems have slipped through. It does not give developers immediate feedback and is expensive to do for multiple devices. Also, it does not have the same reach as automated testing.

In Summary

Consider the business value of what you are doing at every phase of the software development lifecycle. Special attention should be paid during very expensive undertakings, such as while writing software, and while acquiring and configuring new systems. Write brief business impact statements to help developers and others stay focused on the intent of the effort. When making a justification, consider benefits other than revenue lift and cost reduction: strategic value, risk reduction, velocity, and alternative courses of action.

Let's Make Contact

Getting there should be easy and fast. Please feel free to set up a 30 minute no-risk no-charge business consultation to talk about this, your bucket list, or maybe a cool product or service you'd like me to know about.

click here to book your free business consultation

20180130 0.6.0