Keeping Happy Clients by Taming User Stories

Through my work, as an IT Service Management Consultant I have made some experiences with the importance of User Stories in agile development, and through this article, I will attempt to cover this topic. User Stories are simple on paper, though, more tricky in their application when you have a set of expectations towards your development. In my coverage, I am trying to make the article as useful as possible (read: practical).

User Stories: Getting Inside the Head of Your Client

As an [ITSM consultant] I want [to become better at employing user stories] so that [my client experiences more value]

Above you find my motivation for writing this article, described in a common template for User Stories that emphasize an emphatic user-centric approach.

For the uninitiated: "User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality."

To keep it simple, the User Story approach in agile development underlines the importance of iterative dialogue with the client, where the dialogue is catalyzed by the sparsity of the written; in order to grasp the essence of the given User Story, the client and developer side needs to engage in conversation. Through this method, we achieve a closer proximity to the Acceptance Criteria of the client.

In theory, this method is sound, but what happens when the development is to yield a product that supports an established process such as Project Management? Let's assume that the client has a well-established and well-functioning Project Management Process - is it then enough to make a high-level statement such as: "As a Project Manager I want to become better at controlling my projects"? As a start, yes, to initiate the dialogue with the client to understand what makes a Project Management Process successful in their perspective, though, at some point the development process demands a higher degree of certainty than the loose conversation. The findings need to be captured and exploited in a meaningful manner.

Using Stories to Your Advantage

The first topic of conversation with your client should be: "what are user stories?". Agile, agile, agile... Let's just agree that it has become quite the buzzword, and while many have mastered it, do not assume that your client has the black belt in User Stories, or - even if they do - that they use them the same way as you do.

When you have decided on common terms, you need to decide on a development process. How many steps should the process of story grooming comprise? I learned that the following process was great for our process:

Mapping and ideation: a detailed mapping of the Client's AS-IS process. We need to understand and establish a baseline for our development, in order to successfully create value in the future TO-BE process. The mapping process yields value in itself, as the client is forced to critically represent the current situation, which naturally leads to new findings in regards to redundancies and optimization opportunities.

Draft: a written description of the design to be, as a result of an in-depth discussion regarding the alleviation or complete removal of current pains. This step includes the client's Acceptance Criteria (As a user [...]).

Validation and Estimation: you, as the developer, read and understand the description and author design steps that, when developed, aim to close the gap towards the client's Acceptance Criteria of the draft stage. This is also the point where you estimate the hours to be used, which is a difficult demon to tame, as the scope of stories tend to increase over time, as the client realize that the initial functionality isn't sufficient. More about this follows.

Approval: At this point, the story is taking form. We have the description, Acceptance Criteria, design steps, and estimated effort. Most importantly, these elements of the story are created as a product of a dialogue between the client and the developer. Which brings us to an important step, the approval, in which we tame the ever scope-expanding demon of the Validation and Estimation stage. We avoid scope expansions by getting an approval from the client, where they basically agree that the story in front of them, is the product that they expect to be delivered and that it sufficiently closes the gap towards their Acceptance Criteria. Now, should the customer at a later point realize that they need something else than initially described, then keep in mind: If your development meets a previously approved Acceptance Criteria, the development is sound. If not, it should be listed as a Defect that you, of course, have to repair. Otherwise, the new client need is indeed new and should be listed as an Enhancement. In such cases, please remember to make a new story with the sought after functionality described, instead of adding it to your current story. This will help both you and the client. It helps you in effort estimation, as you can't make estimations on potential future wishes of the client, and it helps you maintain a healthy and trustworthy relationship with the client, by avoiding frustrations originating in postponed deadlines.

In conclusion. Apply User Stories in a mindful manner, meaning that you proactively defend your development from misunderstandings through a concise and agreed upon method.

It is not a definite guide, merely breaching the surface at best, many approaches to agile development exist, and I'm sure that my approach will look different the next time. Ideally, this article gave you some perspective. In any case, I hope you have a great day.