Sprints begin with Product Owners describing their requirements and prioritising what gets done next. MoSCoW (must, should, could, won’t do) selection of what they want and the order they want it in sets the Product Backlog for the developers to concentrate on in the next round of work.

It’s about delivering product increments, which suggests that you’ve a fair idea of what the end product should do, you’ve got a partially working model and the developers are adding that quality polish. It all seems a little tactical.
Where’s the assurance that the optimum choices are being made in the first place? Where’s the strategy? Benefits-led Agile development puts a strategic wrap around tactical Sprints.

Every change to the plan must be weighed against the question, “Will it maintain or enhance the objective?” The business will consider:

• Will the change realise our desired benefits?
• Will it take us off-track?
• Will it offer new opportunities that we must take?

A developer’s flash of inspiration takes seconds, “I can tweak the code and give you X”. The appraisal of X is a significant exercise in change control. The business skill will be in allocating the appropriate time and effort that trades off the new value you may get from changing the project specification against the cost and delay of assessing that value and making the change.
It won’t be an easy task and it will require some mental stamina to keep up. However, it’s a task that has to be planned to ensure that your project delivers benefits and not just capabilities.

Use tools to help you choose good things fast. Some are psychological, ways of thinking that get you past the traps we all fall into when we see shiny things that we want. Others are more practical, devices to add rationality and logic to your choices. The more you can structure and program the administrative decisions, the more mental effort you can devote to the creative stuff. Here we concentrate on the two key points, knowing where to start and knowing when to stop.

The Subjective Start – Starting with the End in Mind

The purpose behind any course of action has a direct and significant effect on the way it is undertaken. The reasons why affect the ways we go about things. If Nelson had gone off to Trafalgar simply with the intent of using up his budgeted stock of gunpowder then he would have fought a very different battle from the one that actually took place.

The same applies for any project, the ends affect the means and ways. Projects talk of acceptance criteria, the things that decide when the project has ended successfully, a sort of, “No-one goes home until…” Define your acceptance criteria in terms of objectives and benefits before you start. Don’t install the kit and then wonder what to do with it.

The Subjective Stop – Endgame

There will come a point when the analysis has to end and the decision made, where you stop asking, “Why” and start acting. The trick is knowing that you’ve reached the right point at which to stop.

Starting with the end in mind requires a clear and simple description of what that end will be. We can affect the process through the way we describe the end state. Only a very confident (or deluded) chess player would describe the endgame in terms of where the pieces will be. Yet we are often very granular in describing our programme objectives. Too often Output Based Specifications run to hundreds of pages with sheets of individual requirements, desires and benefits, a pound saved here, ten minutes there, etc.

This sort of mass objective twists individual priorities and breaks down any common purpose. It’s like playing chess as a team with each player responsible for a single piece. Each heads for its assigned position and sits there without contributing anything to the whole or supporting its team mates in winning the game. That’s why clear and simple objectives are crucial.

Psychological tools

There’s some excellent stuff on the ways that psychology affects economic decision making in Daniel Kahnemann’s book Thinking, Fast and Slow. For now, just be aware that these things exist. Recognising them is a step towards compensating for them.

Prediction:

• Optimism Bias
• Strategic Misrepresentation – Flyvberg
• Anchoring
• WYSIATI – What You See Is All There Is, Kahnemann
• Correlation, not Causation

Delivery

• Illusion of Control
• Confirmation Bias
• Framing
• Regression to the Mean
• Endowment Effect

Picking the next Objective

The Idea Test is a way of testing new ideas against your strategy, goals and context. Before running away with a brilliant new idea, it needs to be checked to see how good it really is and how well it fits with who we are and what we do. It contains three checks to take us from hypotheticals to practicality.

First, we have to understand the context in which we operate.

Choose to change – A new idea, Base Hypothesis. At this stage, this is probably a loose statement of, “Why don’t we…?”
First filter – test the Hypothesis against the context to see if it’s relevant and feasible. Should we do it, can we do it?
Turn the Hypothesis into a Goal. “Why don’t we do X?” becomes, “We will do X, because…”

A Goal / Objective is something with purpose. Start with the end in mind. Then optimise the value of the goal. Determine the benefits required, expected.

Second filter – do the benefits validate the objective? Is your grand plan sensible? What’s it worth and who gets the value?
Next, plan to realise the ends. You want to do it, now work out how you are going to do it.

Third filter – is it practical and economical? Do the benefits outweigh the costs? Do you have a rational and sensible solution that will actually work in practice?

Practical Tools

This is where practical tools come in. If you can program as much as possible into the decision making processes then you save thinking time that you can put to better use.
One of the best practical tools is the Benefits Dependency Network. It is one of the key tools in the Benefits / Value arena. It shows the chains of cause and effect between what you use, do and want, i.e. between the means, ways and ends.

In the Sprint you work towards creating the product increments, the capability that serves your purpose. You make the Means that serves the Ends. Benefits-led Agile is the approach that governs the ideas selected to feed this line.
If new capability is discovered then we have to check that it’s useful. New Means may give us new Ends, a new Objective. So you test the idea, select or discard the Objective and move on.
The BDN sets the strategic boundaries. It determines the limits of what’s desired and the scope of the solution. The Agile development is the tactics that control how the strategy is delivered.

Requirements capture

Scrum and Product Backlog has an assumption that the Product Owner has already done the analysis to select the best product increments to go in the Backlog. What have they used to make their MoSCoW selection? Where is their sense of proportion?

The Benefit Profile form has a lot of headings and can look intimidatingly methodical (or just plain boring) at first sight. It works well when everyone remembers that the tool should fit reality and we don’t force reality into the tool. It’s not so much the detailed list as the things that go into it. They are cultural and fit the enterprise in question.

The aim is to get the right thinking into the requirement, “I want these results (i.e. benefits) and I think this piece of functionality (product increment) will deliver them in the context in which I operate.” We phrase the requirement as Ends from Ways from Means, starting with the End in mind. Having drawn the BDN, we already know what we want (at a high level) and how the connections work. This form puts a bit of rigour and detail into the requirements.

It gets us away from the instant answer of, “I want this solution, the reasons are self-evident but hard to express”, “It’s a no-brainer, I just can’t put it into words”.

By describing each item in the Product Backlog using the same form and process, we can compare our options in a rational way by seeing their value relative to each other. The cultural context of the enterprise will have its own significant impact here. Some groups will go totally anal in the detail they complete. If that works for them, fine. Others will be fast and loose. Again, it’s whatever works. Where both types of group gain from the same process is that they’ve filled in the boxes in the form, in the right order, using a rational mindset and so have both raised the quality of the choices they make.

Put rationality into MoSCoW. Use the Benefit Profile to capture requirements:

• Who’s it for?
• What do they want to see happen?
• How big a deal is it?
• Fit the tool to reality, make it work in context
• Choose Ends from Ways from Means

Things to watch

Preference for action, something must be done. This is something. We must do it.

Incubators, great so long as you resource them properly and let them fail effectively if they have to. Know when to pull the plug and don’t blame the failures. Don’t even call them failures.

Effective failure means you don’t bet the farm. Have a position to fall back on if you have to. Benefits-led Agile, being rational but not rigid, keeps your tactical Sprints within a strategic