put lots of effort into defining their goals and objectives each year and while each of them are critical to the business, not all of them carry the same value.
An agile change program is driven by a continuous improvement effort to quantify and validate goals. Teams need to clarify and come to a consensus on the goals to be achieved, how to determine that the goals have been achieved and what value will be added when the goals have been achieved. Organizations that initiate an agile change program will visually map the change program itself, work on a business value model and then develop their user stories around the major initiatives/goals. This ensures that they know that they are working on the right things in the right order according to the value/effort equation and what it brings back to the business.
As with all the other models, these are built up and improved iteratively. As we discover new or better information, we revisit the models. The Business Value Model™ shows the strategy of a project or organisation.
The premise is to identify the business value drivers and then define them. To define them creates a method to measure whether goals are attained. For example, (1) customer satisfaction will be measured with six?monthly customer surveys and (2) revenue will be measured by the monthly Profit amp; Loss statement of each department. Each measurement is a possible business value driver that will drive the project in the right direction to maximize business value generated.
From here we build a Business Value Model from business value drivers and define the relationships between business value drivers and how we’ll use them to steer the project. For instance, keeping existing customers satisfied is more important than short-term income (a trade off) and employee stress levels must not increase (a constraint). It is this type of root cause analysis that is often neglected beyond the definition of high level goals that seem credible at first.
A Business Value Model will provide a level of detail to support the third practice used to drive adoption of change: user stories. The objective is to define the stakeholders that will drive the change program, their respective goals, the tests and measures for each of those goals, necessary capabilities to achieve them and associated constraints or risks for each.
This exercise allows organizations to initiate a culture of transparency and accountability. It also allows for flow in how a change program moves and operates through a lifecycle.
The completed Business Value Model can then be translated directly into user stories to support the change program and the specific things we’ll work on to get it done.
The practice of user stories in agile is somewhat controversial. Many practitioners seem to have their own view of how to best write a user story.
While a template has merit, the objective is more important. A user story is an agile practice that forces a clear, succinct expression of goals and success criteria into an index card sized paragraph. While it can be larger, the idea is to articulate what you are trying to get done.
Many organizations use heavy documents and presentations to communicate their change programs and, in many ways, the user story is the business plan in bite-size pieces with the added benefit of having each piece valued.
Change programs can be vast, so the objective is not to try and identify every possible objective, but to focus on what the primary and secondary ones are for the company and then prioritize them by business value, something