User Stories for Back Office Systems
This is part 4 of Why Agile Fails. Part 3 can be found here >>>>
Back office systems serve up data and functionality to mobile apps, web sites, call centres, voice assistants and many other channels. By their nature they are agnostic of the end user. It is with teams that develop back office systems that I have found the most challenge in embedding agile practices.
The single biggest hurdle is the writing of user stories. Agile adopters know that a user story is a vertical slice through a user journey. They take the form “as user x, I do y for z benefit”. The purpose of a user story is to break down complex user interactions into simple chunks of functionality that can be delivered as a continuous stream of value.
What do you do, thought, if the user is unknown as is common in back office systems? It is hard to use the taught structure if the system is user-agnostic. Team start off with best intentions, trying all the usual stuff, ”as an API user", “as a client” and other linguistic tricks, but these never really work well as they feel fake and often are already at implementation level. As we all know, stories should be technology independent, if you are already talking about APIs then we have already closed down the creative process.
The lack of a cohesive language around user stories means back office teams gravitate towards Kanban, treating requests as simple tickets into a backlog. This approach obscures the context between the product and the back office system, driving confusion on priority and fracturing the company into disconnected mini-serfdoms. As a result there is a drop in the commercial value from the technology teams.
One of my obsessions is delivering value to the commercial teams. This problem with agile and back office systems undermines that goal, and it happens often enough that I had to find a solution.
The answer came to me in the shape of Darren, an excellent Business Analyst. As a top BA, he thought about process all the time. This makes sense, a company is literally a general ledger with business processes moving money in and out. If you don’t know your business processes then there is no way you can think about efficiency and value.
One day we were talking about the processes that ran as part a particularly complex back office system. This system took inputs from users, but also from real world events that happened asynchronously to the user experience. Darren quite naturally modelled the customer’s interactions as part of the overall system. In fact, he referred to state changes of the process and related these directly to user stories. The light came on! A user story is just a slice through a process, but one where the stimulation of the process came from an event generated by the customer.
If, like me, you started off in the telecoms boom of the 90s, then you will know about Finite State Machines, or FSM. A state machine is a behavioural model. It maps a process onto a finite number of states, with events that move the process between the states. Based on the current state and a given event, the machine performs a transition and produces outputs. A fully defined FSM is deterministic, at no point can an input event cause the state to be unknown. This is exactly what we strive for in good UX, the experience of the user should always be deterministic. Striving for predictability drives the constant simplification of the journey.
These learnings have helped me devise a simple set of steps to create back office systems that work well with an agile development process.
- Define the purpose of the process as an outcome
Clear statement on the purpose of the process. Outcomes are a powerful way to express purpose, covered in my other blogs. Outcomes avoid feature creep and box in the purpose of the system. Outcomes also provide the first breakdown of complexity. They allow you to see the smaller processes that make up the company operations. Outcomes also help differentiate from the process itself and observers of the process who are interested in the inputs and outputs but do not influence the process. - Draw up the state machine for the process
Seems simple, yes? It is amazing how many people don’t. There are a number of ways to draw state machines. For me, UML has an easy-to-understand format, is well documented and universally recognised. Drawing up the FSM makes you think about all the events in the process that delivers the outcome, when they can happen and the relationships between them. It gives you the opportunity to solve race conditions before you get to the code level. Often a state machine for a business process can be captured on a single page. Most importantly, it lets you design the process rather than having the process dictated by current practices. - For each transition write up a user story
I know that the trendy user story is “as user x, I do y for z benefit”. This is just a serving suggestion. There is nothing wrong with a story being expressed as “in state x, when event y is received, do z”. As long as the story is a single transition through a process then is meets the purpose of a story, to break complexity down to easy-to-implement-and-test blocks of valuable functionality.
And there you go, you now have a well defined and testable set of stories that give you 100% coverage and deterministic behaviour. It is best to use this format alongside the traditional formal of the user story defines the experiences for the observers. These two methods gives you the ability to capture completely both the process and the observability of the process without losing sight of the importance to deliver a complete system.
