4
It's a good question. From a Scrum point of view the product backlog and the sprint backlog together encompass all the things that are being done or that are on the list to be done in future. So the term backlog refers to the full list of items no matter what their status. Status information is usually shown against each item on the backlog.
However, I do ...
4
I'm not familiar with Azure DevOps, but I assume they have the concept of Epic available. You should be able to have a common "login" Epic with different Stories for each Platform.
You'd keep the core of the requirements at the Epic level (to avoid duplication) and then the Stories (or tasks) required for each platform linked to this Epic.
3
Disclaimer: The first time I read the question, I thought it'd have a straight answer. After reading it again, it may not be as straightforward as I originally thought (or maybe I'm overthinking).
From Cambridge dictionary, a backlog is a large number of things waiting to be done.
Therefore, once an item is no longer waiting to be done, it shouldn't be ...
3
This is going to be highly dependent on the context.
I'll start off by saying that "checked into production" doesn't mean anything. Is that "checked into an integration branch in source control" or "checked into the main branch of source control" or "deployed to production"? All of those can be very different things, ...
2
Using ideal time - days or hours - is both practical and viable.
Although my personal preference is to not assign estimates in time, points, or size to work and to focus on making each unit of work the smallest useful, demonstrable slice that can be used to elicit feedback and counting the units of work per unit of time for planning, estimating in ideal time ...
2
Here is a link that outlines how to write good acceptance criteria. Some highlights:
Each acceptance criterion is independently testable.
Acceptance criteria must have a clear Pass / Fail result.
It focuses on the end result – What. Not the solution approach – How.
Include functional as well as non-functional criteria – as needed.
Team members write ...
2
I think that having an answer to the question is more important than what the answer is.
Decide on what you believe is the purpose of the backlog and make sure it is communicated widely. Work with it for a while and see how things go. If you experience issues, adjust the way the backlog is defined and again make sure everyone is aware of the change.
1
I think you can define backlog as you see fit, based on how you organize and think about work as well as how you communicate work to your stakeholders. The definition you use needs to resonate.
For me, I like the dictionary definition @tiago wrote in his answer. It resonates for me in that work listed in my backlog has to mean the work has not started or was ...
1
How practical is using days estimations for stories in a sprint instead of another approach
In my practical experience, it's entirely impractical and counter productive.
It doesn't really matter whether it works well or not, the name "day" is already taken.
And for higher ups, it's ambigous. If you write "it takes 5 something something days&...
1
Can you help me understanding how can I verify/validate the system like I used to in the previous approach?
Agile does not mean vague. Quite frankly, you are right. Those acceptance criteria you have problems with are just bad. That has nothing to do with agile of any kind. Acceptance criteria should be testable. If you as a QA person do not know how to ...
1
Refer to the Definition of Done (DoD) and Working Agreements
In [S]crum, when do developers typically check their [S]print code into production?
There is no prescriptive answer within the Scrum framework, and it's not defined by the 2020 Scrum Guide. Additionally, "delivery" in a Scrum sense is not strictly aligned with the Sprint Review, which ...
1
Adding to the answers you already have...
An increasingly common approach is to release code when it is ready, regardless of when that happens in the sprint. The use of feature toggles allows this to happen and means we can separate out 'release to production' from 'release to customers'.
So, the general rule is:
Release to production behind a toggle when ...
1
I think this is not the SAME user story but 3 comparable stories
As a Web user ....
As an IOS user ....
As an android user ....
Probably also
As multi plaform user I want same user experience on all platform.
INVEST your stories => INDEPENDANT
A troll approach is "if you need to keep all in ONE story (even it's splitted in many subtask), so that ...
1
Gantts tend to be useful when the audience reading the Gantt is more interested in tasks and dependencies than outcomes. Most of the space on a Gantt chart is taken up by the tasks whereas only a small amount of space is used for outcomes (milestones).
In knowledge work, research, creative, operational support and software development work for example, the ...
Only top voted, non community-wiki answers of a minimum length are eligible