9.2 The general view of agile with respect to the Business Case theme
In a mature agile environment a business case would be created in some form. As part of the vision and product roadmap there would be sufficient information to ensure that the work is appropriately justified and that it is strategically aligned. This would need to take place before release planning takes place.
In some agile environments there may not be as much emphasis given to the concept of a formal business case, possibly for the following reasons:
- Teams talk in terms of the delivery of ‘value’ instead.
- The most common agile ways of working focus more on the value of delivering individual features rather than assessing the totality of the features as a whole in advance. Work is prioritized (in a product backlog) by a product owner, in an ongoing manner, based on value and maximizing that value. In effect this plays the role of a business case and is authorized by the product owner.
Definition: Product owner
The role assigned to managing the product backlog in order to get the most value from it by ordering and prioritizing it.
It is important to understand that in some agile environments this does not mean that a business case is not needed or is undesirable; it may just be assumed that one exists or that the rationale for the work being undertaken has already been justified.
Scrum for example starts with a backlog of features – when Scrum is used in a project context it assumes that this backlog has already been created. In a BAU environment, a backlog will already exist and each entry on the backlog is prioritized on its relative merits in relation to the value it will deliver. In a project environment, upfront work is required (such as creating a backlog) and this would include the evolution of a business case, which would need to be authorized before delivery work could commence. A mature agile environment would cater for this although there is not a commonly agreed standard for how to do this or what it would look like.
Definition: Visioning or project kick-off
An exercise or phase that aims to understand the overarching goal of something (e.g. a project). It would try to answer questions such as: Why is this work taking place? Who is it for? What might it look like?
One common approach that is used is to have a specific sprint at the beginning of a piece of work in order to address many upfront activities (e.g. forming a team, visioning, defining the architecture) and understanding and approving a business case would be part of this. This is commonly referred to as sprint zero (or iteration zero or (the) discovery (phase)) but the following points should be recognized:
- There is no formal standard for what sprint zero looks like.
- Sprint zero is perceived both positively and negatively by the agile community.
- The Scrum Guide (see Appendix H) does not support the concept.
Definition: Sprint zero
A specific sprint at the beginning of a piece of work in order to address many upfront activities (e.g. forming a team, visioning, defining the architecture). Also referred to as iteration zero or (the) discovery (phase).