![]() A need is a loose description that will lead to one or more requirements should the need be funded. If you have Portfolio management, then define a Portfolio Epic as a top-level need. As such, an Epic is a container that is meant to hold actual requirements once defined properly. This way you know that whatever is in that epic, it is not useful until it has been broken down into smaller pieces. My suggestion is that you define the term Epic as a level top-level requirement. So you need to deal with them and you need to define them in a way that makes sense for every scenario. If not in your systems, then people will use the term based on how they have used it in the past. ![]() Regardless if you work in an organization that claim to be Agile or not, you will most certainly come across the term Epic. That would suggest that an Epic is defined on the level where it is placed and depending on how you divide between need and requirement the term Epic would be a top-level requirement in both situations, or they would be a top-level need when defined as a SAFe Epic. As a top level requirement it fit both the team or system based focus as in Agile methodologies like Scrum, but it also fit the SAFe Epic definition, which I think is interesting. I think Epics are more similar to top-level requirements, but I think the fact that they can also be similar to mission threads illuminate the problem with Epics. Parallel Worlds: Agile and Waterfall Differences and Similarities Because Epics can represent an end-to-end capability, they are also similar to mission threads. This is most similar to a system specification or top-level requirements(TLRs). I found this definition I thought fit pretty well: In traditional development, we don't have Epics, but we can translate it based on the definitions used in Agile. Just to make things worse, you even have methodologies named EPIC. Are you working with strategic themes? I bet you have some strategic Epics as well, right? How about focus areas? Do you have epics there as well, maybe? How about your requirement process, I am sure you have heard your product owner talking about Epics on multiple levels as just things that are undefined in their mind? The difference seem to be that the Portfolio Epic is a funding without scope or time frame, which to me is the same as an extra budget for research and development or some form of business operation scenario.Įpics can be found pretty much in all tools you look at, and in companies you will find that the term "Epic" is just as abused as the term "project" or "Initiative" as it is applied to everything. It becomes even muddier when Portfolio Epics in SAFe leads to Business Cases with high level estimations, which projects also need. SAFe even have a specific definition to define that an Epic is not a project, which should tell you how vague the Portfolio Epic is in SAFe. SAFe recommends applying the Lean Startup build-measure-learn cycle for epics to accelerate the learning and development process, and to reduce risk. Portfolio epics are typically cross-cutting, typically spanning multiple value streams and Program Increments (PIs). Due to their considerable scope and impact, epics require the definition of a Minimum Viable Product (MVP) and approval by Lean Portfolio Management (LPM) before implementation. ![]() If we go up a bit within the Agile sphere, then let us see what SAFe says about their epics:Įpics An Epic is a container for a significant Solution development initiative that captures the more substantial investments that occur within a portfolio. Since much work starts on the business side even in Jira, then it is very common to have the Jira Epic turning into a Portfolio Epic. This means that you can have pretty much any size of task in a story, and it can be anywhere from full features to a small configuration. A User Story is related to Requirements, not tasks), which in the best case will be defined as some form of work that can be done within an iteration (sprint most commonly). ![]() In Jira for example you have a Story (Not User Story as defined on their website. This vague definition of something big, cause all kinds of problems, especially if what the Epics are broken down to are poorly defined. ![]() In other words, it is something that has not yet been broken down fully and remain a bit vague because of that. So in both examples it is something big that can be broken down. Epics are an important practice for agile and DevOps teams. An agile epic is a body of work that can be broken down into specific tasks (called user stories) based on the needs/requests of customers or end-users. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |