Creating a Value Statement
Many clients aren’t concerned with the specific features and functionality of software at this stage. It’s more important for them to nail down the business requirements that should be based on their vision or goals for the project.
source: scrum.org
One value statement may not cover the needs to be addressed and the business solution for every customer the client wants to serve. If this is the case, they should develop a value statement to target each group of customers. The final set of value statements will describe the functionality and business solution that are required to meet the needs of all users.
Developing the Value Statement into a Business Outcome Hypothesis
The value statement should capture the major goals and functional requirements of the project, but we then go into more detail by using it to create a business outcome hypothesis. This hypothesis has several important functions:
- It states the quantitative and qualitative benefits that the business can expect if the hypothesis is proven to be correct. These benefits may be in terms of users affected, the expected impact on processes, products, services and costs, sales, revenues, etc.
- It defines leading indicators that can be used to help predict the eventual business outcomes. Some examples of leading indicators include the number of users, subscriptions, costs per user, etc.
- It determines nonfunctional requirements, which are features of the software solution not related to its functionality, such as which architecture and infrastructure it uses, how the software is built and updated, network usage and bandwidth, performance, availability, security, backup, stability, capacity, regulatory details, usability, interoperability, costs, configuration, documentation etc.
If you’re new to the idea of using hypotheses in software development, the concept is not so different from the hypotheses you were probably asked to develop as part of high school science class. You’d then carry out an experiment to test this hypothesis.
You can think of a hypothesis as a “prediction” or “best guess” of what the project will achieve.
An example of a basic hypothesis for software development might be something like: “We believe we can reduce our support requests by implementing a chatbot that will instantly answer frequently asked questions. We’ll know this is true when the number of support requests is reduced by X amount.”
We then test this hypothesis in the leanest and quickest way possible to find out early in the development process if the solution currently in development is fit for purpose.
source: scaledagileframework.com
By using this method to define the scope of the project, we avoid adding unnecessary features or focusing on the features themselves rather than the business outcomes.
Other Information Needed Before Development Starts
Developing a business outcome hypothesis is a key concept in agile software development, and it helps us to make sure we’ve defined the full scope of the project before any work starts.
In addition to this formal process, we also capture and discuss other business-related information with the client that may be necessary or helpful for planning development. This may include:
- A detailed description of business process steps
- Definition of user stories and use cases in general
- User personas (with roles in the system)
- Minimal viable product features (the must-have features of the final solution)
- Additional potential features (the nice-to-have features of the final solution)
- Major milestones and deadlines.
By establishing the groundwork and expected business outcomes of your software development project in the beginning, you won’t just have a more seamless experience. This is how you’ll get the results you want to see.
