7
votes
Accepted
Should the Product Owner (PO) or Software Engineer Own the Feature Item?
It is clear that the individual software engineer owns a 'user story'.
Let me be clear, we are not talking about Scrum here. We are talking about how to best squeeze Scrum into the ticket management ...
7
votes
Accepted
Should I have user stories dealing with the case where user is not authenticated?
Short answer: yes, it is perfectly fine to account for negative cases.
I'm used to seeing this a bit differently. Usually a User Story is one step up
like:
As a user, I'd like to be able to ...
6
votes
Should I close very old feature requests
Should I close very old feature requests?
Yes.
A backlog with 1000 items is rarely a backlog. For a big product, with many team's working on it, maybe that's fine. But something that contains five ...
5
votes
Accepted
How to build a feature backlog bottom up
You might consider using a technique like story mapping.
It would also be worth having a conversation with the team about how they define value. With a clearer idea of that you will be better placed ...
4
votes
Accepted
Could my sprint unit be a scenario instead of a feature? (Gherkin terms)
First I'd like to say that this is a wonderful experiment. Please chronicle your experience and share it with the world.
We are uncovering better ways of developing
software by doing it and ...
4
votes
Should I have user stories dealing with the case where user is not authenticated?
Capture Business Concepts (Not Engineering Steps) In Gherkin
Is it a practice I should keep?
Maybe. Negative test cases, like boundary conditions, are good things to test from a quality assurance ...
3
votes
Should I have user stories dealing with the case where user is not authenticated?
TL;DR: Yes, you may keep it this way.
Long Answer
Depending on what you are using the scenarios or business rules for, there are several ways to write them down
First case: The scenario is used for ...
3
votes
Could my sprint unit be a scenario instead of a feature? (Gherkin terms)
Well, there's JIRA Epics that would fit your features and Stories could be your scenarios. You should play around with using epics, stories and sub-tasks to best suit your needs.
I think the method ...
3
votes
What are the different approaches and how frequent to prioritize the backlog?
Let me tackle the two parts of your question slightly separately.
How To Prioritize
The Scrum Guide says that "The Product Owner is responsible for the Product Backlog, including its content, ...
3
votes
PI Planning and user stories without features
Differentiating Between the Team-Level Critical Path vs. "Hidden Work"
There really isn't any such thing as a "standalone story" in either SAFe or Scrum. In general, all work ...
2
votes
Accepted
How should I control a programming project's progress?
Oh the memories, first project. Due to your small group size and the high uncertainty of your project, I'd chose an agile approach, e.g. Scrum.
So form a cross-functional team that is covering every ...
2
votes
Should we encourage a team member adding a feature on his own?
His dedication, enthusiasm, or skills is not relevant. The only thing relevant is that a change was introduced without approvals. Controlling change and configuration are leading practices and changes ...
2
votes
Should we encourage a team member adding a feature on his own?
Puh, I've been through this several times. Some lone-wolf-developers can be hard nuts to crack.
Let's have a look how Scrum handles this: team members should be encouraged to write user stories - ...
2
votes
Accepted
Reopen an epic after a feature request?
You create a new Epic with a similar name
The key point here is this: after some time - if the customer already signed off on the original feature, it was right to close the Epic. If they've ...
2
votes
How can we decide if a story is a feature or just an internal change?
TL;DR
The distinction is largely irrelevant from an agile perspective, but may have other drivers that require you to evaluate and adapt your process. If you must do so, involve the entire agile team....
2
votes
Correct Work Item Hierarchy in Azure Dev Ops
PBIs should not be treated as something different from epics or features. Epics, features, requirements, and tasks can all be product backlog items.
In Azure Devops the hierarchy is as below:
Epic
|...
2
votes
Correct Work Item Hierarchy in Azure Dev Ops
The Epic is just a bigger Feature which itself might require smaller features (multiple User Stories) to get Done.
It goes like this:
When an item is first added to the Product Backlog it is ...
2
votes
Should the Product Owner (PO) or Software Engineer Own the Feature Item?
The presence of the 'Assignee' field in Jira lowers velocity by completely destroying teamwork -Jim Coplien
This reflects my own experience! Team assigns an item to a person, person becomes ...
2
votes
Organizing testing in a Scrum(ish) development project
There is nothing scum(ish) about this project
Team members are not involved in deciding what can be accomplished in the sprint. No sprint planning. It is top-down.
No coordination among team members ...
2
votes
Bug Vs Feature Development
When you receive a bug report, it needs to be triaged. The workflows that I use tend to look something like this:
Review the bug report and confirm that it truly is a bug. Some people who report ...
2
votes
Does it make sense to test business functionality before doing a code review?
It seems rather nitpicky to determine if the order of reading code and performing any manual testing, especially since it's an iterative process.
Since it's not stated, there's an assumption that the ...
2
votes
When T-Shirt sizing Epics, should the size be based on 1 person's capacity or the teams capacity?
It doesn't matter as long as a) you are consistent and estimate every story the same way, and b) you can tell your business leaders what the conversion factor is.
There are additional layers of ...
2
votes
Accepted
PI Planning and user stories without features
In SAFe, the Feature is the core artefact for value delivery. Because of that, adding a column into a report should in theory be linked to a value expected to be perceived by users.
The PI planning ...
1
vote
How to build a feature backlog bottom up
A really fun way is doing a Design Sprint. Followed by some Impact mapping and User story mapping.
Depending on your product get out of the freaking building and let the developers talk to actual ...
1
vote
How to build a feature backlog bottom up
As mentioned in other answers, you can go for story mapping exercise but first you may consider aligning all stakeholders to a prioritisation framework and high level objectives/ themes/ Epics (for ...
1
vote
How to build a feature backlog bottom up
I think Scrum does exactly what you want. The team as a whole add items onto the backlog (backlog refinement) and the Product Owner is the person on the team who sets the priorities.
If you don't yet ...
1
vote
Does it make sense to test business functionality before doing a code review?
Post-Hoc Testing is an Anti-Pattern
You have succinctly described the use case for test-first development. In general, you want to first determine if you've built the right thing. Then you need to ...
1
vote
In an Azure DevOps work item Excel file, how do I assign parent without having to see closed siblings?
The excel add-on works nicely but you may want to look into importing via CSV.
Benefits:
Regex can be used to mass-edit
Files can be versioned
Changes aren't reflected in ADO until you upload the CSV
...
1
vote
Blocked due to a dependency
It depends on how and why it was blocked.
If it was known that there was an unresolved dependency going into the Sprint, I would consider not bringing it into the Sprint to begin with. Minimally, the ...
1
vote
Correct Work Item Hierarchy in Azure Dev Ops
The Scrum Guide does not say anything about the backlog other than there is "items" in it. So consider the following my experience, not the official guide:
The Product Owner should be able to decide ...
Only top scored, non community-wiki answers of a minimum length are eligible
Related Tags
features × 24user-stories × 10
agile × 8
scrum × 7
epics × 5
product-owner × 4
planning × 3
safe × 3
team-management × 2
jira × 2
project-management-style × 2
requirements × 2
product-management × 2
tasks × 2
bugs × 2
devops × 2
reviews × 2
software-development × 1
estimation × 1
kanban × 1
sprint × 1
methodology × 1
backlog × 1
quality × 1
tfs × 1