Making UAT more agile: Functional slicing

In the first article in this series, we looked at why UAT fails and what good looks like at a structural level. This article goes deeper on one of the most effective ways to change the model: running UAT in functional slices, rather than waiting for a single big-bang phase at the end of the programme.

There is a version of UAT that nearly every large retail technology programme defaults to: All the development work completes; all the testing phases run; and then at the end, the business comes in and accepts everything at once.

It sounds logical, but in practice, it's one of the most common ways to turn UAT into a crisis.

By the time users arrive, the programme is typically behind schedule and there's pressure to get through acceptance quickly. The system has never been seen by the people who are now being asked to sign it off and if something goes wrong (and it usually does) there's no time left to fix it before the go-live date.

The alternative is not complicated, but it requires discipline.

What functional slicing actually means

Rather than treating UAT as a single phase that follows everything else, you identify which functional areas are ready for acceptance and bring the relevant users in to accept those areas, while development and testing continues on others.

For example, order management is ready and proven so you bring in the order management team. The returns process is still in system testing so that team stays out until it is ready to be tested.

This isn't parallel running in the problematic sense. And it isn't dropping users into an unstable system because the programme has run out of time. It is planned, sequenced acceptance, with a clear and enforced boundary around what is and isn't ready.

The distinction matters. A programme that stages UAT based on genuine readiness is fundamentally different from one that launches everyone at a half-finished system because the go-live date is set in stone.

Why functional slicing reduces risk

We believe the business case for functional slicing is very strong.

Firstly, it spreads the business impact. Rather than pulling key colleagues out of the business at the same time, you stagger their involvement. The business keeps running and the people in UAT are focused on their specific area rather than trying to absorb a whole new system at once.

Secondly, it gives you an earlier signal. If the order management journey has a fundamental problem, you find out during order management UAT, not during a combined acceptance phase where everything is in flight at once. That earlier signal gives the programme time to respond.

Finally, it reduces the pressure that causes poor decisions. The big-bang approach creates a deadline that the whole programme is racing towards. When that deadline arrives and UAT is not going well, the conversation quickly becomes about what can be descoped or deferred rather than what actually needs to be fixed. Functional slicing distributes that pressure across the programme, rather than concentrating it at the end.

The entry criteria question

Sequencing acceptance across a complex programme

On a large retail technology programme with multiple platforms and workstreams, the sequencing question becomes more complex. Some functional areas have dependencies. You can't accept the returns process until order management is in, because returns depend on orders existing. Promotions may depend on pricing. Reporting may depend on almost everything else.

Mapping those dependencies early, as part of the programme's test strategy rather than as a UAT planning exercise, is what makes functional slicing work in practice. It is the same principle that applies to testing before coding: the earlier you think about what needs to be proven and in what order, the better placed you are to run a programme that doesn't collapse under its own weight at the end.

The sequencing also informs how you resource UAT. If order management acceptance runs in weeks eight and nine, and returns acceptance runs in weeks ten and eleven, you can plan business user availability accordingly. People are out of the business for focused, bounded periods rather than for a single extended block. That is a materially better outcome for the business, and it makes it easier to get senior, experienced users into the room rather than whoever is available.

What this looks like in practice

A programme that does this well looks quite different from the default. There is a UAT schedule that maps functional areas to acceptance windows, with clear entry criteria for each. There is a testing strategy that sequences development and testing to support those windows. Business users know when they are needed and for how long. Change champions are in place before the first session starts.

When something goes wrong in an early acceptance window, there is time to fix it. When something is not ready, the entry criteria provide cover for the decision to hold. And when UAT does complete, it completes with confidence, because it has been building to that point in stages rather than hoping everything holds together under pressure at the end.

What "done" looks like is a question worth answering before UAT starts, not during it.

Next in the series: The change champion model in practice: how to set it up and what it delivers.

Sign up to our monthly ctrl freaks emails to make sure you don't miss it.