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 system with templates that VSTS is. In Scrum, if anybody, the development team "owns" a PBI (for example User Story) in the sprint backlog. Multiple individuals ...
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
As a user, I'd like to be able to add a meeting on the calendar so that I can track my schedule for the day"
Then I would have both of these as acceptance criteria on that story.
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 helping others do it.
The Manifesto for Agile Software Development
Jira doesn't have a concept of features, but it does have Epics. You could enter your features ...
I think you have the right place. ie the backlog. But only if you are actually going to do them and they should be at the TOP!
If you aren't going to do them, I suggest a 'will not fix' or 'phase 2' dumping ground column/tag/board but don't kid yourself that they will somehow be picked up and done magically without taking up time you want spent doing other ...
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 perspective. However, from an engineering or product management perspective, it's worth asking why you need a narrow scenario like this rather than either a ...
TL;DR: Yes, you may keep it this way.
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 acceptance criteria
As a user, I want to create meetings, to...
Authenticated user may create meetings over a GUI / API
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, availability, and ordering." At the end of the day, the Product Owner has final say over which of the criteria you listed is the best way to prioritize the backlog. ...
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 you are describing would be a very good experiment to do - see what happens!
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 in the form of a Daily Stand-up.
Team is not attempting to create a potentially shippable increment at the end of the sprint.
Team is not showing the work ...
TL;DR: On the top of the product backlog.
Sounds like your tasks are not DoneDone. Completely finish and make features production ready before picking up any new features.
You don't want to reserve time later to make it release ready, because how much time you need is uncertain, but more important context switching is expensive. Fixing or finishing tasks ...
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 accountable for that item. Feels a lot like favoring tools and individuals over interactions!
The whole Team is accountable for delivering the Increment and achieving ...
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 aspect of development. And decide what rules are irrevocable when the shit hits the fan (and it is going to hit it real hard, trust me). You need a solid rule ...
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 out of control is an undesired practice. You don't have to analyze impacts because they are already well known.
Just teach your guy about change management. ...
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 - especially technical ones. And agile PM-methodologies also know the concept of a Story Owner. Plus thinking above the own tellerrand is in the vibe of DevOps. So I ...
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 essentially now got new requirements and wish to enhance the feature, by all means track it in a new Epic named something like 'Feature v2'. I recommend you find out ...
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.
Analysis and Recommendations
Is something a feature only if it's customer facing?
Does a non-customer facing internal update count as a feature too?
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 developer who did the work didn't just write code and throw it over the wall. They tested it, by some combination of writing automated test code as well as ...
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 issues may not be aware of the intended behaviors of the system. The issue reported could be acting as designed.
Assuming that the issue is a bug, check the quality ...
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 to prioritise the backlog.
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 determine if you've built the thing right!
With that said, the notion of divorcing functionality from code correctness is a false dichotomy. In order to meet a ...
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 conversation should be had to determine what the risks are for planning on completing a given piece of work with a dependency that may or may not be met.
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, being the top-level requirement.
The goal is to break down anything that'...
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 unrefined, meaning somebody just added it there and it needs to be discussed during the Product Backlog Refinement meeting. This meeting anticipates what will be ...
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 whether something is an Epic, a Feature or a User Story. Because it's not about how complex it is or how long it takes, but what it is to the product. There is ...
As others have written, accounting for negative cases is good. However, the structure of your negative case is not, because it contains an internal contradiction.
The problem is that you are describing outcomes as if they were user actions. But they are actually the action the software takes in response to the user action. Failures have user actions, but ...
How can I keep track of open bugs/tasks from previous sprints separate from product backlog items related to new functionality?
You shouldn't even try! One of the purposes of the Product Backlog is to act as a parking lot for things related to the project that may never be reached during the project lifecycle, but that should be captured.
By keeping the ...
I my opinion, it depends on what is the objective of your product. According the Scrum Guide regarding Product Backlog responsibilities:
Ordering the items in the Product Backlog to best achieve goals and
I think that any decision must be made together with your client, what is the product mission. In my company, usually I use ROI first to ...
Business requirements changes found via defects?
This sounds like that PO's requirement are off course from the customers expectations.
Agile is all about empirical feedback, so if your customer is telling you that there is a defect in the system, you make that a new user story and get the PO to prioritize it for the next sprint. If you add this to an epics ...
Move away from Epics and trying to deliver the whole. There is always a PBI from an EPIC that is not as important as other PBIs in other Epics.
So try to change your colleagues' mindsets to focus on delivering the PBIs (user stories) and not focused on Epics.
If you find something as a result of a defect, it is a sign that something is not working ...
My project is also in active agile development of a newly released product.
The primary purpose of my tests is to ensure that we don't accidentally break something that we have already delivered, so I focus on adding test suites for features added in each sprint.
Thus, in your situation, I wouldn't have any qualms about adding tests that match user ...