In the video above, I explain how to break an epic down into a number of user stories. In a previous video, I explained what an epic is: essentially, a short narrative describing an idea for an AI application in terms of its goal, the value it represents, its size and scope, and how long it is expected to take to deliver. You create an epic to use in quarterly planning; often, an epic becomes part of what’s called a quarterly business review, or QBR.

But an epic is described at too high a level for a development team to build, test and implement. That’s why we break an epic down into user stories. A user story is a short, simple description of end-user needs. User stories are not functional descriptions or requirements; instead, they clarify what end users want, what they need and why. They’re written from the perspective of a specific stakeholder.

Here’s an example of a user story about Monocam, an AI application used by the National Police; you can see a photo of it above:

‘As a police officer, I want a MONOcam AI application that checks whether a driver on the motorway is holding a mobile phone, so that the number of accidents caused by distracted driving goes down.’

Another user story about that same MONOcam would be:

‘As a driver, I want a MONOcam AI application that does not film the passengers in my car, so that their privacy is protected at all times.’

You’ll see that this user story follows a specific structure:

AS …. I want … so that I …

In short: As a [end user], I want [a description of the AI application] so that [a brief description of why the AI application should be developed]. The examples show that AI applications are generally developed for several different end users. A user story is always written from the perspective of one of those end users.

There are two important things to keep in mind when writing user stories. First, as I just mentioned, always write user stories using the format: As X, I want Y, so that Z. This immediately makes it clear who the user story is for, what is being developed, and what value that development will deliver.

Second, make sure you write your user story according to the SMART principle. SMART stands for specific: describe the goal of a user story as specifically as possible. You can think of it as writing a mission statement for your goal. M stands for measurable: which metrics will you use to determine whether you’ve achieved your goal? This lets you measure progress. Also think about which milestones are important for delivering the outputs within an epic. Then there’s achievable: explain how important a goal is to you and what you can do to make it achievable. Bear in mind that you may sometimes need to develop new skills or change behaviour. You might need specific tools, or have to bring in external specialists. Fourth, how relevant is the user story? Focus on something that supports your broader business goals. For example, if you want to build an AI application to help sell a new consumer product, but your business goals say the company isn’t planning to expand into the consumer market, the user story isn’t very relevant. The final aspect to consider is time-bound. Anyone can set goals, but if the timeline isn’t realistic, you’re unlikely to meet them. Set a realistic and achievable delivery date for the outputs in the user story; sometimes, it also works well to timebox the work to fit the time available.

Once you’ve held an ideation session, described a number of epics in an epic one-pager, and written user stories, it may be a good idea to present your results to the decision-makers and AI specialists in your organization. An Obeya Room is a handy solution for this: put all the results up side by side on a wall and invite everyone to come and view your dashboard:

Those were my tips for developing ideas for AI applications in your own organisation, step by step. Good luck putting your next steps into practice!