New answers tagged

1

Agile is not a religion; there is no Agile Scripture; there are no Agile Priests. should all user stories be linked to an epic, or could some stories stand independently on their own? The basic answer to your question regarding "Must Use" is No; at least, not in any formal way. As a matter of formality, the entire purpose of "Epics", &...


0

It's more or less a question of formality in order to keep the process clean Formalities are a convention, not an empirically proven solution. Whatever has been communally decided to be used (or singlehandedly decided to be communally used) is how you should tackle this. can I let a user stories stand on its own without linking it to an epic? If you're ...


1

Agile methods such as Scrum, Kanban or others don't define any process regarding user stories or epics. It's all about backlog items. Your only duty in this matter is to keep the backlog effective. User stories are a proven effective way to do so. Creating systematically epics, even when a need is expressed as a simple story, might create unnecessary ...


4

What do you mean by "Epic"? It's not a well-defined term or concept. Sometimes, the term "Epic" is used as a short, simple way of saying "unrefined story". When you have a backlog of work, not everything is necessarily refined to the point where it's ready for a development team to take on. Work that represents a stakeholder ...


0

Running to fixed-duration Sprints containing a pre-agreed workload simply does not fit with any, realistic, "Support" model. "Stuff" happens as and when it wants to happen and it cares not a jot about your precious Sprint cadence, your prioritised Backlogs, your Ceremonies or anything else. To Paraphrase Murphy's Law: If something can go ...


2

Ultimately the one that works is Modify the current sprint - this can work from time to time, especially for missed feature requests, but for standard operations type stuff - small requests - this would bog down the team in a lot of process. Part of the point of Agile is not having to stick to a big upfront plan. If you're doing that you're just doing a ...


4

You have two options: attempt to project a level of support and plan for this at your Sprint Planning for each team or create a support team that operates using their own cadence (perhaps a just-in-time flow). If you have a good idea of the volume of support and operations work each Sprint, you can allocate time each Sprint for the teams to do that work. If ...


0

we could perhaps have a new team, which uses a different process - Kanban? Something else? - to handle all of this kind of thing [...] Is this a good idea or a bad idea? You have a customer need: work that needs doing on a timescale quicker than your sprint cadence. On the basis that this would fulfil that need, it's a good idea and one which I've seen work ...


1

Whatever process you choose you essentially have the same problem. "Development of new features is too slow". Scrum, and agile in general, tries to maximise developer productivity and align with business planning by focusing on one thing at a time. Obviously there is some slack in the red tape and you can squeeze in the odd extra 'emergency' thing ...


Top 50 recent answers are included