Agile Business Coach

Business Value Driven Development

The diagram below shows Business Value Driven Development.

The starting point for any project should be the business strategy. We ensure allignment to the strategy by developing a business value model that is alligned to the strategy using the Grid Model and Market Maturity Model. The business value model should be barely sufficient. If you are doing a 5 man day project, a few minutes spent working out the numbers might be sufficient. If you are doing a $10 million project, then it might be appropriate to spend more than a few days on the model.

Once we know why we are building a system, we can work out a "to be" process. To develop the "to be" process, we may first map the "As Is" process. My preference is to draw these process models on white boards or by hand on paper rather than put them into visio or a case tool (spit). These process models should not be regarded as deliverables for the project but rather as muda that is a necessary evil to understand our requirements. If you are spending more than a few hours on these you are doing too much.

From the "to be" process and from our discussions with the business, we develop the master story list. Stories on the master story list take the Form "As an X, I want Y, so that Z." The Z comes from the business value model. The X and Y come from the process. The stories should be recorded on index cards. The master story list is actually a stack of cards.

At this point, we can use the master story list to produce estimates for the project.

The estimates combined with the output from the business value model can be combined to give the return on investment for the project.

The estimates and business value model outputs are fed into the risk matrix. After all, the risks are that the project costs more than the estimates and the business value is less than the model predicts.

A really useful exercise at this point is to bring an HCI specialist to develop the user experience from the master story list. i.e. What the application will look like from an end users perspective.

The next step is to specify the detail, the acceptance criteria, for the story. The business coach specifies the acceptance criteria in the form of JBehave scenarios. This is done for the candidate stories for the next iteration. The acceptance criteria are specified in the format

GIVEN a context ( a set of givens )
WHEN an event
THEN an outcome.

The developers can then perform a more detailed estimate for the stories.

As soon as your business sponsor has identified your highest priority stories for you first iteration, you can start development. You do not need to have a complete master story list before development starts. In fact, we expect to add and subtract stories from the lilst. Is there any choice other than XP for the development? The cards for the current iteration should be placed on some wall space so that all the team can see them and sign up for development.

The first step in the development is to generate the JBehave classes from the JBehave story.

The developer then uses Behaviour (Test) driven development to develop the stories.

At the end of each iteration the business decides whether it wants to implement the software in production. The software should be implemented as often as possible to prevent the build up of software inventory. The business should then measure to ensure the business value is released by the software.

Posted by chrismatts at December 15, 2004 3:37 PM