DEV Community

Discussion on: Engineering guide to writing correct User Stories

Collapse
christianschulze profile image
Christian Schulze

Thanks for the response Nikita, however I don't think I was clear enough with my question.

Ignoring any acceptance tests, dealing with just the story:

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

So this was for using webhooks, but coming back for a second sprint to add push notifications I'm unsure how the new story would be written, since it doesn't contain any implementation details to differentiate from the original story. What do you think?

Thread Thread
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.

Example:

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

  Examples:
    |payload|
    |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.

rgalen.com/agile-training-news/201...

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.