First take what Amon said.
Next, if you think your “insert” branch is fine, you want it tested before merging obviously, but you want to continue work without waiting:
You can branch “update” from the “insert” branch that you know it needs. As soon as “insert” is merged into its parent branch, you merge the parent branch into your “update” branch, and it’...
A (user) story is a helpful standard format for backlog items. The rationale behind it is "if no one cares about it, don't waste time on it". It also allows the PO to assess the urgency of the item because it defines whom you will be doing it for and how bad it is.
In your case the bug can easily be formatted as a story.
As a user
I want to be able to log ...
Distinct specifications of changes and additions to the product, are
called Product Backlog Items (PBIs), that together form the Product
Each PBI describes something that the Developers can develop and
deliver to add value to relevant stakeholders when Done (see
Definition of Done).
The most common stakeholder is the market, or its representative —
The statements that you claim should be true in Scrum aren't necessarily true in Scrum, according to the Scrum Guide.
It is not true, according to Scrum, that you should be estimating user stories in story points. The Scrum Guide mentions neither user stories nor story points. In Scrum, you have a Product Backlog that contains Product Backlog Items, and one ...
The official Scrum answer is "Estimate complexity not time and use Story Points"
However, on a practical note I would say estimation is not something you want to get hung up on. There are a couple of main objectives scrum is trying to achieve which impact estimation.
You can measure progress towards the story in terms of completed tasks.
This means that ...
In sprint planning, flesh out the tasks involved for each story, and estimate these in hours.
I've never split stories into tasks or estimated something in hours. You can do Scrum without any of that if your stories are well defined and small enough.
Instead of trying to do the impossible (estimate in hours without knowing who will do it) just improve your ...
I don't think there is a clear answer to this. It depends on what your team needs and your solution. Let me explain:
Generally speaking in agile our goal is to provide end user value. There is a risk with API or other tech stories to create something that is of no value, or at least out of context. Imagine a story as in "I want API xzy to retrieve the ...
Stories are a tiny piece of functionality, a piece of code that is testable and provides some value. As such the workflow should be that they are raised, analysed, coded, tested, released.
As such these are owned by the team as a whole and as part of the work pipeline will transition from one 'discipline' / expert to another. If you must, you can use sub-...
I personally think the analogy (and use of) chickens and pigs is a helpful one. None of the teams I work with use it any longer.
Imo it was invented to focus standups. So here is the thing: a standup is there to facilitate delivery. Mainly to unblock the team. Remember, it's not a status update. It's a quick run-through to ensure the team can deliver.