I’ve recently come across a “user story” in an electronic project-management tool: “As an application, I want to invoke an API to get grades from a course.”

An experienced agilist will notice right away that this “story” lacks a user persona. An application calling an API is not a persona. A novice might ask, but we don’t really have a user persona, all we’re trying to provide here is a connection point for other applications, which can be used by different types of users for a variety of purposes.

The answer is of course to identify users of such applications. In university courses, there are teachers and students. If we write this story from a student’s point of view (assuming the user persona is a student), it might look like this:

But from a teacher’s point of view, it would look very differently:

What are the differences?

1. Data sets. In one case, we’re getting grades assigned to one student (all grades for homework, tests, mid-term, etc.) in a course; in the other case, we’re getting a matrix of such grades for all students.
2. Security. When students try to access grades, the business rules are very simple: they allow any student to see their own grades in the course they’re taking. Therefore, the system only needs to authenticate the students and check that he or she is enrolled in the course. But downloading the grade matrix probably requires additional permission checks. Even then, there may be different access levels; for example, the professor can access the entire matrix, teaching assistants can access only certain subsets of its rows, etc.

We can now see clearly that there are two completely different user stories here. And identifying the user persona made all the difference.