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?
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.
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:
So this was for using
webhooks, but coming back for a second sprint to addpush notificationsI'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?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 existingScenarios. And cover new corner-cases inside newScenarioblocks.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.