A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.
7

Both Developers and Executives Broke the Agile Contract It was due for a release tomorrow but, as a result of a review by management, needs reworking. This will undoubtedly add a lot of time onto the estimate for release. You have a basic process failure if the first time your management team reviewed the product was shortly before release. In particular,...


5

I think the crux of your question may actually lie in questions you posed in a comment, rather than in the question itself: Do you find it acceptable that release dates are not met? The answer is... it depends. It really depends on the situation; on the project itself. If it is a purely internal project that is a 'nice to have' or some such thing? Yes, ...


4

TL;DR Some frameworks have a distinct name for the type of work you're asking about, but some don't. To understand why, a short preface is in order. Work is work. While it's sometimes necessary to differentiate different types of work for cost-accounting or political reasons, treat this as an opportunity to educate your organization and your stakeholders ...


3

If I understand your situation correct you are looking for a way to help teams to talk about/analyze/assess what areas to improve and give the people that supports these teams (mangers, coachers, etc.) a high level summary of what’s working and what’s not. Based on this I would recommend you to look at the Squad Health Check model by Henrik Kniberg. What ...


3

There are a few points to consider on this. 1) Scrum uses PBIs. Product Backlog Items are all the things that make up the product backlog. Any item that you have to do can be an item in the product backlog. You can use user stories and spikes, and all kinds of other special techniques in doing your work, but there is nothing that says "Walk the dog" isn't a ...


3

This is normally addressed with resolutions. In your case you need to have the following resolutions configured: Released - Deploy Required. Released - Deploy Not Required. So the person who is going to handle the tasks will use the filter like this: project = "Sample Project" and fixVersion = "Release.2018.03" and resolution = "Released - ...


3

Releases are a hugely significant aspect of Agile. There are many reasons for their importance, including: We value feedback and a released product gives us an opportunity to receive feedback from the end users. Doing a release collapses a lot of unknowns, such as "Will it work on the production server?" and "What will be the impact on production ...


2

TL;DR In any agile framework, if you want to estimate based on fixed scope, your estimated release dates will vary. If you opt instead for a fixed release date or routine release cadence, then it's scope that varies. Both are legitimate options, but in this case your delivery manager is more right than you are. All Sprints are Potentially Releasable Your ...


2

It is not clear if your team is doing production support or software/ app dev. Assuming it is app dev, there are a few questions to consider - What is the customer's need for the releases your team is making? If there is no pressure from customer to do a release or if the pressure is sporadic or infrequent, then there is nothing much your team can do ...


2

First thing is first: Kanban has no queue columns. This is an anti-pattern. To elaborate, a Kanban board is a visual representation of a workflow. In workflow mapping, we do not represent wait states as steps in a process, rather as notes in the transition from one step to another. Further, this indicates work being pushed to the next step instead of ...


2

I would encourage you to sit with your team (perhaps in the retrospective) and take a look at the values in the Agile manifesto: http://agilemanifesto.org/ Customer collaboration over contract negotiation is something to consider spending some time on as a team or selling to your stakeholders. You may benefit from holding stakeholder demos more frequently. ...


2

If it is stable, release it for beta testing The only reason not to release it for beta testing is if it is not stable enough. Especially, if there is possibility for data loss. You run the risk of losing some users for good, if they get frustrated. Otherwise, the earlier you release it for beta testing the better. Of course, be transparent with your users ...


2

The answer for this question is, at the end, dependent on how you'll use this information. So, why do you have versions at all? You have to think about this before asking how to manage versions. Think a bit longer. Get the answer. Got it? Ok. (Disclaimer... this answer may NOT fit your need) From a project management perspective, what you usually want ...


2

Agile is all about (sometimes brutal) transparency. If the initial feature release requires a lot of expense and effort then that is what should be reflected. The release of Customer Facing Feature 1 has involved a lot of time, effort and cost A good agile organisation will question this. Perhaps they will ask: Is this really the minimum viable release?...


2

So, I need to assess the health of the engineering process as it currently is and make recommendations for how to get it to a better state moving forward. As this is an agile environment the questions I would be asking include: Are the teams themselves failing to self-improve? Are the teams empowered to fix their own problems? Is the working environment ...


2

Estimate Delivery Milestones from Throughput You have half a solution already. While your scheduling process isn't particularly agile, you can extend what you're already doing by calculating cycle times and using that to estimate your release schedule. At the risk of oversimplifying, you an get a reasonable estimate of your release date by doing the ...


1

To determine which approach to use you need to dig into the implemented product architecture (not by yourself but with the team) and try to map its relevance with product's roadmap. In case you understand that architecture and technologies used for the implementation are still relevant for the further product growth: should I create my release around the ...


1

This can be confusing because there is no authoritative body that sets terminology for Agile and, therefor, there is not "right" answer. But, these definitions and distinctions should be close. Roadmap The roadmap provides stakeholders with a view of how the product might roll out. Many teams do a planning that is longer out than a sprint but within about ...


1

Some of that initial infrastructure can be demo'd to customers at sprint reviews to help educate them on why and how it is delivering things that are of value to them. For example, CI/CD: "Look, my tests will run every time I commit/merge something! And if I commit something wrong... (do so)... look, it tells me right away! This buys us both quality and ...


1

I've been placed to the same circumstances for years. And the approach of having the versions for each particular component showed poor efficiency (at least in my project) due to Jira specific. Jira versioning is well-designed when you version the project as a whole and does not support component versioning. So the best solution is to consider migrating to ...


1

By the book is as @Daniel mentioned, the team decides who will own this responsibility. However there are other variables that could help on defining this, for example, who's your client (marketing area, app user, other internal areas of the company)? Is your client aware of release communications? If the client is prepared and used to the process (and ...


1

The Scrum Guide is intentionally sparse on detailed responsibilities. There are some delineations that are important for Scrum to work properly and it calls those out - all others it leaves up to the team. The things you mentioned are not things that are expressly called out, so I would say it's up to the team to decide who will do the work. There are two ...


1

Your thinking assumes several fallacies which have been evidenced time and time again. The idea that software engineering is accurately estimable (it's not, estimates merely become more accurate as we progress towards completion). A healthy backlog of work with some basic estimating and a maintained burn-up chart would have shown that from the start. The ...


Only top voted, non community-wiki answers of a minimum length are eligible