Working Through a User Story

Question

I am trying to tighten up my process for tackling a feature request. Currently, we use trello to manage feature requests using cards. They typically look like this.

Card Title: Invite a friend
Card Description: Allow the user to send an invite.

I then interpret the feature and start writing code to fulfill the request. I sometimes have to stop in the middle of coding and message the client or project manager questions like "Is this just for a regular user? What happens if that email already exists? Where should the link for the invite page go? etc..

I am getting into writing user stories and it seems to bring more of the conversation upfront and is helping with the planning phase of a feature, but I feel like there should be at least one more step before writing code.

As an example say we are working on a web application that allows teachers and students to communicate. We get a feature request to allow the user to send an invite. This feature has three scenarios.

Scenario 1 User Story

As a: Student I want: to invite my classmate So that: they can communicate with our teacher.

Scenario 2 User Story

As a: Student I want: to invite my teacher So that: we can communicate within the application.

Scenario 2 User Story

As a: Teacher I want: to invite my colleague So that: they can comunicate with their students.

What is the best way as a programmer/developer to break this out as part of the planning phase before writing any code? How can I break this user story up into something developer related and I can refer back while actually writing code. I use TDD so I usually would start writing the tests with the code that I wish existed and simply start writing the classes and methods to satisfy my test. Can I do something similar with a user story?

Answer 1

It sounds like you are looking for BDD, and the Gherkin specification language. The gherkin language is a way to express business scenarios that can then be used to stub out code-level tests. Once you have your test stubs, you can start implementing the solution using more traditional TDD red/green/refactor style methods.

Here’s a blog post on it: https://medium.com/@SteelKiwiDev/how-to-describe-user-stories-using-gherkin-language-8cffc6b888df

There are BDD frameworks that can read gherkin scenarios in multiple languages so chances are you can get started in whatever your developers are comfortable with.

Answer 2

Hm. I look at your three scenarios and I see a dependency that worries me: scenario 1 seems to assume that you've already delivered scenario 2. When this happens to me, I look for alternative ways to split the story. At a minimum, this leads me to ask, "What's really different about these three scenarios?" Maybe nothing. Maybe I only need one scenario.

Or maybe there's some asymmetry here. Does a person need special permission (authorization?) to invite another person? This sounds like something to explore with someone who knows the domain and the intended behavior of the system.

Let's say that the system needs special authorization rules. No problem. I'd write the first story as allowing everyone to invite everyone else (honor system), then add more stories for each "interesting" kind of authorization rule. Once anyone can invite anyone else, then each additional related story refines the feature by disallowing invitation requests that shouldn't be allowed. This is good for a number of reasons, but if the system has serious security/privacy concerns, then you might need to flip that around, so that you start with "nobody can invite anybody", then add permissions one story at a time. Trying to split the larger story into smaller ones tends to lead me to ask questions about potential unspoken assumptions. We don't want to wait too long to hear, "Well of course we have authorization policies... who doesn't have that?!"

For me, the killer technique is Talking in Examples. When I discuss a story with anyone, I relentlessly describe examples that illustrate my current understanding of the story. This way, the other person has the opportunity to hear my example and tell me how I have it wrong. That moment leads to learning a detail that I needed to build the right system. I do this over and over, collecting these details. I keep trying to describe simpler and simpler examples and that prompts the other person to "fight" to add important variations back. Within a few minutes I know a lot. Within 15 minutes I almost certainly know enough to get started without heading off in completely the wrong direction. Then I build stuff (TDD or not, whatever works for you), put something in front of them, and then get more feedback. In examples. Again and again. It Just Works.

Those examples, by the way, can become automated tests to drive the behavior of the system. Automate them however you like, depending on how actively the Customer will participate in writing and refining those examples. Just remember that 90% of the value of those examples comes from the talking, not the automating.