DEV Community 👩‍💻👨‍💻

Discussion on: Engineering guide to writing correct User Stories

sobolevn profile image
Nikita Sobolev Author • Edited on

That's the most important part: your user story does not change. And it should not be duplicated as well.

You can write new Scenarios in the same file. You can even use parametrisation to inject dependencies to some of your existing Scenarios. And cover new corner-cases inside new Scenario blocks.


Feature: Tracking issues progress
  As an architect
  I want to have up-to-date information about Gitlab issues
  So that I can overview and track the issues' progress

  Scenario Outline: new valid <payload> is received
    Given <payload> is valid
    And <payload> is authenticated
    When it is received
    Then a new issue is created

    |issue webhook|
    |push notification|
Thread Thread
christianschulze profile image
Christian Schulze

Right got it, thanks for clarifying 👍

Thread Thread
ltvan profile image
Van Ly

Once a user story is done, it should not be back to backlog. If you have some enhancement, create new story.

You can write like this:

As an architect, I want to receive notifications on my mobile when there is any update from Gitlab

Thread Thread
ltvan profile image
Van Ly

Ah, I might misread your scenario. In case that you mentioned about the push notification between GitLab and your system (in additional to webhook), you may create a technical task to address the issue.

In the end, technical task should only be considered if it has some business value in it. Try to find some way to describe the value, otherwise, if you want to go fast and the product owner and stackholders understand the value behind the lines, then just use technical task.