The following figure shows an example User Story that you may recognize from earlier in the book. There are three sections to it, shown as follows:

The basic template we're using for this User Story is:

• As an <actor> I want <some action> so that I get <some value>

We can either define the actor as an actual person, "Kimesha, a cinema-goer", or as a persona, "a Cinema-Goer." The subtle difference between the two is just the name "Kimesha", but this can be surprisingly humanizing. A real person like Kimesha is far easier to picture in our mind's eye, and so we're less likely to objectify our customer when we're building software for them.

It also opens us to the fact that there is more than one type of cinema-goer. Sometimes we want to be specific, and sometimes we want to generalize. It does mean that we're more likely to have conversations among the team that go a little like "Kimesha just wouldn't do that, but another cinema-goer might. Why would Kimesha do something different and how can we accommodate it?"

We should shy away from using the term "user" as the actor, as this is too broad in definition. Being specific will give us much better context and will help us to implement something of worth to that person.

The action is what the actor will perform using our software, and is what we'll be implementing for the actor to get the value. The value statement is probably the most important part because it's the actual value our customer derives from carrying out the action.

In this instance, our actor Kimesha, the cinema-goer, purchases cinema tickets via our software and in return is able to reserve guaranteed seats for a movie.

Crucially, the value statement scopes the work we have to carry out to implement the action. For example, we're building this feature for our cinema-goer to reserve a seat to see a movie, not so the cinema manager can determine how many people are attending a particular session. That's another story (pun intended).