EPIC added to the Sprint backlog

I feel it is not a good practice to have epic in the PBacklog and added to sprint and estimated.

@Venkata Naga Aditya Charan, Why do you feel that the epic can't be a part of the Product Backlog? If it is not a part of the Product Backlog, then what would be the impact on Transparency?

@Steve Matthew - Sorry If I'm unclear with my question, but I wanted to ask is can we the Epic estimated just like user story with story points and then add to the sprint backlog? 

Have the Development Team estimated that work, and do they consider it "ready" for Sprint Planning?

The Scrum Guide says:

Product Backlog items that will occupy the Development Team for the upcoming Sprint are refined so that any one item can reasonably be "Done" within the Sprint time-box. Product Backlog items that can be "Done" by the Development Team within one Sprint are deemed "Ready" for selection in a Sprint Planning

Ian Mitchell - Yes the development team have estimated the Epic and ready for planning. But they didn't sliced into user stories. The expected outcome of the epic is small and the development team said they didn't created user stories out of it and sized epic directly. Is that Okay to do? My question was can we have Epic directly sized thought it's small and have it as an increment ?? Thanks.

That is a perfect example of what tools like Jira do with our perception. Forgot for a while about names like Epic, in the end, everything that is known to be needed in the product is a Product Backlog Item, and going after Ian, if the Development Team assess that PBI is sized reasonably for the Sprint, why do you bother about the names (Epic or whatever)? Maybe you just use them incorrectly and you don't have a shared understanding of what specific name, such as Epic, means in your context, and why labeling PBI as Epic is important?

Thanks everyone I'll take back the point that whatever the needed in the product is PBI and if the development team assess that PBI is sized and can be delivered in the sprint then it can be in the Sprint backlog / scrum board 

Also, Will discuss with team and will draw agreement on using the names such as Epic. 

Thanks.

Thanks everyone I'll take back the point that whatever the needed in the product is PBI and if the development team assess that PBI is sized and can be delivered in the sprint then it can be in the Sprint backlog / scrum board 

Also, Will discuss with team and will draw agreement on using the names such as Epic. 

This is precisely the right course of action.

The second part - agreeing on the terms - is vital. The word "Epic" is a good example. Traditionally, an "Epic" is simply a large User Story that hasn't been well-refined by the team yet and is likely something that will be decomposed into units that are more easily designable, testable, and deliverable. However, some tools (Jira is an example that I'm familiar with) use "Epic" as a container for other work (like Stories or Bugs) and it allows for a higher-level view of groupings of related work. I think both uses have their merits, depending on your need, but it can be confusing if everyone isn't on the same page as to what it means.

FYI: Azure uses a feature to group PBI's and an epic to group features.

Those terms can be helpful but they may lead to discussions as well.

However, a lot is known about a PBI, so that is the best concept to start with.

I would care less about whether the Product Backlog items are Epics/ Features or User Stories. We need to keep in mind that the Product Backlog is a progressively elaborative artifact and the items become progressively refined and discussed as team decides to take it up in the new-future Sprints.

Just to site an example with Story Points (its not a compulsion on teams!), a Product Backlog can have refined Stories with thinly sliced functionalities (with 1,2,3 or 5 Pointers each) which are placed towards the top in order of priority and on the other hand, can have large Stories (of an approximate magnitude of a 50 Story Points) towards the bottom of the Backlog which is yet to be discussed and refined by the team as they are not on the immediate-priority order.

So, in case you have an Epic, it either should have already been refined by the team with the just enough details and clarity to be taken up in the near-future Sprints and hence should have been broken down into consumable & estimable Stories or just be kept there towards the bottom of the Backlog if not an immediate priority and subject to be taken up later for refinement. 

Hello,

If you will see document of Azure DevOps or Jira then you can easily solve these types of issues.

We are using CMMI level in Azure DevOps in our organization and managing epic, features, requirements easily with it.

Please see this link : https://docs.microsoft.com/en-us/azure/devops/boards/work-items/guidanc…

So, we can devide Epic -> Features -> Requirements/CHR -> Tasks

we are creating EPIC roead map in Azure DevOps.

EPIC = Collection of Features.

Features = Collection of Requirements,CHR,Bugs

Requirements and CHR = Collection of Tasks.

Here, We are creating feature timeline also. in that features may complete in single or multiple iteration.

Finally, in ProductBacklog, we are taking fequirements and CHR only ( not features or epic )

If you will take EPIC in sprint then it may not complet within a sprint or few sprint. So how will you see potential increment at the end of sprint. I think alwasy you will find many un-done work items at the end of the sprint if you will take epic into sprint and you will carry forward those many items in next sprint which is not good practice.