New answers tagged

0

One dimensional backlogs are a thing of a past I would say. At least 2 dimensions are used in well structured backlogs, in some cases even more. Dimensions: Priority Time frame Logical group Readiness / Status But again, there is fine line between good backlog and complicated pile of work items. An live example of such backlog both in Kanban and list ...


4

[...] working in a small SCRUM team (capacity ~ 3 FTE) that must deal with multiple projects in various stages Scrum works best for one team working on one project. If you have things coming your way that can't be planned in advance, then you will need to put aside a capacity buffer for those things so that the stable part of your sprint still has a meaning ...


0

TL;DR The focus on representing automation as a separate step is a bit of a red herring, although that doesn't mean the automation problems aren't real. What you're dealing with is really an X/Y problem caused by a lack of smooth process flow. The solution is to review your entire process for waste, friction, and unnecessary steps. You then need to revamp ...


0

I don't think the problem is the automated steps, but the overall process flow. A few things to consider: It's not entirely clear on the differences between "Reviewing" and "Verification". It seems like you are developing in branches, so why can't the code review process account for ensuring that the changes satisfy the team's Definition ...


0

TL;DR Generically, a backlog is a project or product management artifact that represents potential future work. As such, it's most useful to think of it as a register of future work within the project rather than as a top-level status or a container of work states. I provide additional detail below on what backlogs are, how to conceptualize them as planning ...


0

tl;dr: The Backlog is a list of items, tasks or activities representing work that has to be done; the breakdown of such items and their statuses during the workflow is a Kanban Board. By definition, the (Product) Backlog is a list of items, which contains or derives into the list of activities/tasks needed to complete a step in the process. The two ...


3

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.


0

I generally agree with the answers already given, but would like to emphasize the context and purpose of the backlog, which in turn determines its best implementation in a given setting. Basically, the backlog is the list of items known to need to be worked on but not yet started. As such, it does not include stuff that you don't know yet, and also not stuff ...


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 ...


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 ...


5

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 ...


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 ...


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 ...


0

Pushing code to production is the latest step in the journey of a code. Here are the steps I use; Developer creates a feature branch on source control related to a story/task Developer pushes code ( including test code ) to the feature branch The "continuous integration" service runs the tests on the feature branch The code is reviewed by peers ...


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, ...


0

Relative estimation works because people are generally better at relative estimates than absolute ones; relative estimates are easier to manage (because they seldom need to be re-estimated) and velocity is evidence-based rather than purely based on forecasts and guesswork. It is possible to use "ideal days" as the unit of relative estimation - but ...


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&...


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 ...


0

I would suggest you start by thinking about what is involved in providing insurance. Then, imagine you are starting a new company that is going to be selling insurance. What would you need to do to sell your first insurance policy? These steps would then feed in to the phases of the project. What requirements would you need to gather before starting? What ...


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 ...


0

I want to start some thoughts on this question. When does text become a story? When the Product Owner (PO) accepted it? When did the Description of Requirements accept it? When did the idea emerge somewhere? ... The idea behind these questions is that any user should be able to state a request, an idea, feedback, ... and therefore create an item. The PO ...


0

Project management is about risk, specifically managing risk. One is the largest risk being a failure to deliver a project to budget and within the agreed timeframe. Many times I’ve explained to junior project managers that it is better to focus on project risk, rather than activities or resources in a Gantt chart. Isolating risks in a project ensures you ...


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 ...


0

I would also add that Gantt charts are NOT useful if you have little idea how the project may progress, which is particularly true for pure research projects, PhDs etc. Often the team may be small anyway which would also further limit usefulness of Gantt chart. If you are forced to use Gantt chart by your manager/supervisor then you will end up updating the ...


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.


Top 50 recent answers are included