Your Sprint Board is not an implementation backlog.
Mapping AI opportunities gives leaders clarity about what matters. It does not mean the organisation suddenly knows how to build everything. The next job is to turn priority into evidence.
At the end of an AI Framing Sprint, something interesting happens. For the first time, an organisation can start to see where AI could actually operate.
The organisation has mapped its people, roles and tasks. It has looked at the work rather than starting with the technology. From those tasks, it has created use cases: specific candidates where AI might augment a person, automate part of the work, or eventually operate more agentically.
Each use case describes an outcome. What are we trying to improve? What does good look like? What might we save? What might become faster, better or more consistent?
Then those use cases start appearing on the Sprint Board.
And this is where organisations can make their next mistake.
They look at the board and see an implementation backlog.
It isn't.
The Sprint Board is not a list of things you now have to build. It is a one dimensional expression of where leadership believes the organisation should put its attention next.
The Sprint Board is a judgement call.
There is no formula that can perfectly tell a leadership team what should go first.
A use case might say it could save 20% of someone's time. That matters. But perhaps implementing it means the organisation will not need to hire another person next quarter. That might not appear in the original calculation at all.
Another use case might have a smaller measurable saving but solve a major customer problem. Another might remove a bottleneck preventing a team from growing. Another might matter because leadership believes it will create a capability the organisation is going to need everywhere else.
Those are leadership decisions.
That is why I do not like pretending that every use case can be reduced to a weighted score.
There are no scores on the Sprint Board. The numbers simply represent order.
First this. Then this. Then this.
Priority tells you where you want to go. It does not tell you whether you know how to get there.
Look at both sides of the coin.
How much do we want this?
What does good look like? What might it save, improve, protect, unlock or avoid? What strategic judgement makes this important now?
What would have to be true?
Do we have the data, connector, SOP, environment, security approval, skills and measurement needed to discover whether it can work?
When leadership puts a use case near the top of the Sprint Board, it is effectively saying: we want this.
The next question is not necessarily, how do we implement it?
It is: what would have to be true for us to make this work?
Perhaps the data is available but there is no connector. Perhaps the process is understood by the people doing it but there is no usable SOP. Perhaps the model can perform the task but security has not approved the environment. Perhaps the API exists but nobody internally has the skills to connect it.
Those things do not automatically make the use case a bad idea.
They tell you what you need to learn.
Imagine you had one developer for one hour a week.
If you had one capable developer for one hour, once a week, what would you ask them to work on first?
Not ten developers. Not an AI transformation programme. Not a six month implementation roadmap. The constraint forces the Sprint Board into an ordered learning queue.
You might not ask them to build the customer service agent.
The use case provides the reason for doing the work. But the work itself starts creating building blocks.
- The connector created for one use case may unlock another six.
- The security pattern established for one experiment may become the pattern used elsewhere.
- The first proper model evaluation may give the organisation a repeatable way of testing models.
- The SOP work may reveal that the process itself needs fixing before AI should touch it.
- The measurement approach may become the way every future use case proves value.
The use case gives you a reason to build the capability. The capability makes the next use case easier.
This is where EVA begins.
EVA is a simple way of moving a use case from leadership intent to evidence. It deliberately avoids jumping from idea to scale.
Experiment
Take the highest priority use case and start learning. Set up the environment. Try the model. Test the prompts. Build or identify the connector. Find the data. Tighten the SOP. Work through security. Discover what access is required. Identify the skills you do not yet have.
The objective at this stage is not to finish the use case. The objective is to reduce uncertainty.
Can this work here?
Validate
Once something works technically, return to the original use case. If we said it would make the task 30% faster, did it? If we expected better quality, did quality improve? If we expected to release capacity, did that capacity actually appear?
Validation is not about defending the original business case. It is about replacing assumptions with evidence.
Does it actually deliver what we said good looked like?
Accelerate
Only when there is evidence should the organisation push for more. Increase adoption. Automate more where the evidence supports it. Move through Augment, Automate and Agentic where appropriate. Reduce human intervention where it has been earned.
Acceleration does not always mean scaling the same thing. Sometimes it means moving through the rest of the Sprint Board faster.
Now that we have evidence, what has it earned?
Every experiment should leave the organisation knowing more.
An experiment can produce three useful outcomes.
The evidence supports continuing.
Another building block needs to happen first.
What you learned changes the opportunity.
The evidence says the opportunity is not worth pursuing.
All of those outcomes create value because they replace uncertainty with knowledge.
The board should change as you learn.
The Sprint Board should not be treated as a promise made at the end of the Framing Sprint.
It should move.
Experiments create information. Information changes judgement.
A use case that looked like number six may suddenly become number two because a connector now exists. A use case that looked incredibly valuable may move down because the experiment reveals significant complexity. Two use cases may collapse into one. Another may disappear completely.
A new opportunity may emerge that nobody could see when the board was originally created.
That is healthy.
It captures leadership's best judgement based on what is known now. EVA creates what the organisation needs next: evidence.
Evidence earns the next decision.
This is where EVA connects naturally to EARN.
Has the workload earned further investment?
Has it earned automation?
Has it earned Agentic operation?
Has it earned Frontier model capability?
Has it earned the operating cost?
Has it earned less Human In The Loop?
Has it earned acceleration?
This creates a very different approach to AI execution.
You do not need to know how to build everything on the Sprint Board. You do not need every connector on day one. You do not need every skill internally. You do not need to solve the entire architecture before beginning.
You need to know what matters most. Then take the next useful step that reduces uncertainty.
Experiment to learn. Validate with evidence. Accelerate what earns it.
That is how a Sprint Board stops being an overwhelming list of AI ideas and starts becoming a practical path for building organisational AI capability.
The AI Framing Sprint helps leadership teams map the work, identify the use cases and create the Sprint Board. EVA provides a practical rhythm for turning those priorities into evidence.
Read more about the AI Framing Sprint →