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||issuewebhook||pushnotification|
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
That's the most important part: your user story does not change. And it should not be duplicated as well.
You can write new
Scenario
s in the same file. You can even use parametrisation to inject dependencies to some of your existingScenario
s. And cover new corner-cases inside newScenario
blocks.Example:
Right got it, thanks for clarifying 👍
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:
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.