Published June 29, 2022
by Doug Klugh
One Actor per Story
Write user stories for one specific actor to facilitate the development of a loosely-coupled, modular architecture. This will promote compliance with the Single Responsibility Principle to ensure that functions, classes, and components have a single reason to change. Writing stories that service a single actor will also help achieve Separation of Concerns. Avoid writing stories for a generic “user” as this will provide absolutely no value at all.
One of the main components of a user story is the actor to which the story provides value. This ensures that the user story services exactly one actor — one user role. As stories service different actors in different ways, this helps to separate (decouple) the responsibilities between actors. Different actors will have different reasons for changing or extending the same functionality. Identifying the one actor the story services promotes alignment with the Single Responsibility Principle — which ensures that components, classes, and functions have a single responsibility — a single reason to change.
Anyone who has taken Agile training knows that we learn to write user stories on day one. We all learn the standard format for a user story as follows:
As an <actor>, I want to <function> so that <benefit>, unless <exception>
Indicating the actor does not just improve readability, it helps the developers separate the responsibilities of each class/object in order to deliver a modular software solution. In order to do that, they must know specifically which actor a user story serves. Building quality software requires us to build separate classes for each individual actor — because each will likely have different reasons to change the functionality represented by a user story.
While use cases often serve multiple actors, the realization of a use case must not. It must only serve one actor. The same is true for user stories, for the same reason. Responsibilities must be kept separate.