New answers tagged user-stories
1
TL;DR
It's not a bug, it's a misfeature. The Product Owner needs to decide how much of a priority it is to address it, and then the entire Scrum Team needs to either build a Sprint around it or squeeze it into the margins as a non-essential work item as capacity allows. TAANSTAFL. You can't have it both ways, and you can't treat new work (which this is) as &...
1
Since a there was no common understanding, the developer will prefer the change as new user story as creating a bug will indicate a failure on his part. (all said and done someone is still watching the quality of deliveries and keeping count of defects/bugs). Focus should more importantly be on preventing this sort of thing from happening again as the code ...
2
There is something that needs to be done for the product. You can convey that information no matter what the ticket type is. Scrum doesn't say anything about stories or bugs. It just has a Product Backlog Item that will become a Sprint Backlog Item.
In the Scrum framework process is left up to the people doing the work to decide.
So I will say your team ...
2
Focus on how to prevent this from happening again
As pointed out by others, if calling it a bug is contentious, call it a story. That is the easy part. Also, as pointed out by others, I recommend that you focus on how to prevent this from happening again:
Have you discussed this in a retrospective following the discovery of the issue? What ideas did you ...
2
As a rule, try not to differentiate bugs from other stories. What matters is what you want to do about the issue in question and what priority it has. The development team should feel free to label things as a bug if it helps them but that kind of label can be contentious so it may be better simply to label everything as a story.
7
Doesn't really matter. Just be consistent.
Scrum (I'm assuming you're using Scrum, given the 'Product Owner' tag) doesn't differentiate between bugs and user stories. It really just depends on how your specific business wants to track things.
More than just your testing failed.
Generally, by the end of the Planning Meeting, the entire Scrum Team should have ...
2
Does it really matter how you classify it? Regardless of if you call it a "bug" or a "user story", the end result is a change to the system. In some environments, maybe it does matter, but in others, it may not. If you don't need to make the distinction, then I would eliminate it entirely.
If you do need to make the distinction, I'd ...
2
TL;DR
You're conflating engineering and architectural domains (and especially source code management tooling) with business and project management concerns. There's no direct mapping between product increments and merge requests, especially in large or complex systems.
Think of a vertical slice as the thinnest piece of coherent, full-stack, multi-layered ...
0
It feels like there's a (potentially well intended) intention how development and architecture should work based on agility principles.
As well intended as it could be, the way the question is framed implies this may not be working. I'll approach the technical aspects (merge, commit, pull request, repo) from engineering perspective. The "agility" ...
0
This is a pretty common situation in most work settings - where teams work on a mix of work large (projects/ epics) and small (tasks/ user stories/ tickets, etc.) Work also occurs in "natural" hierarchies - portfolio initiatives - programs - projects - tasks, or epics - features - stories, etc.
Luckily, Kanban is great at "scaling" as it ...
0
I have dealt with this issue when coaching hardware testing teams, and the solution was to borrow the concept of an "epic" from Agile methods for iterative development. The definition of "epic" I am using is simply a requirement or "user story" that provides customer value, but for legitimate reasons it cannot be completed in a ...
0
A sprint is a time-boxed event. In that event, everybody must complete some stories and provide output.
Mobile and backend developers can work in parallel for the same story, but the designs of that story must be ready before they can start. This brings us to create a separate story/task for the design. When the story/task for the design is completed in a ...
0
I wouldn't get too caught-up here in etymology. This is a requested change to a general section, aspect or "feature" of the product, and as such it needs to be formally tracked. Such things can fall under the auspices of one "story" or maybe several ones. When people write the original version of a "story" they don't always ...
1
Do you have one team or multiple teams? Your description isn't clear on this. If you're doing Scrum, you really should be working with one team that develops a common understanding of complexity of stories.
Story point estimation is only applicable if it is done by one team in consensus. This may involve discussion and re-estimation if initial estimates by ...
2
When evaluating user stories, everyone should consider the total effort required by the team to finish the narrative. As a result, the back-end developer should not only estimate the time it will take him to complete his portion, but also the time it will take him to complete the front-end, mobile, design, and all testing (and similar for the other team ...
Top 50 recent answers are included