How to deal with epics

1. Backlog items are ordered by priority which is calculated by business value againt cost. So the items that have the highest business value and will cost the least are put at the top. So knowing the estimate is pretty useful.

2. Epics are placeholders for stories, so they proide metadata context about a story but also promise future Conversation. (The Three C's). So personally I dont think its needed or even advisable to split all your epics up. Too much initial refining could lead to waste.

You could follow the 20/30/50 rule of backlog management. 20% ready to go, 30% well formed stories and smaller epics, and 50% large scale epics.

Hope that helps.

Posted By Justin on 13 Apr 2014 07:52 AM
1. Backlog items are ordered by priority which is calculated by business value againt cost. So the items that have the highest business value and will cost the least are put at the top. So knowing the estimate is pretty useful.

2. Epics are placeholders for stories, so they proide metadata context about a story but also promise future Conversation. (The Three C's). So personally I dont think its needed or even advisable to split all your epics up. Too much initial refining could lead to waste.

You could follow the 20/30/50 rule of backlog management. 20% ready to go, 30% well formed stories and smaller epics, and 50% large scale epics.

Hope that helps.

Let’s say the customer (PO) is an external party and the deadline is based on a budget.

So the customer has a deadline (end date) in mind. He presents the stories so the team and wants to know an initial estimate of when all of this is done.

During the refinement session the team detects a couple of small stories, but also big epics. The customer is a bit familiar with scrum and knows that requirements will change overtime etc. Still the customer needs an initial estimate from the team.

Does the team estimate the epics? Or do they need to spend time making it all smaller in order to give an estimate?

So the PO's date is fixed but not the scope? If your team has a constant velocity then you should be able to give him some dates, but remember that your estimates are not supplied in hours. They should be supplied in story points or however you like to work, but the point is that they are not time based.

If you can estimate the epic and its low on the value scale then I think go for it. If its impossible to estimate but is high in value then you should split it up accordingly. If its middle of the road then leave it as an epic. 20/30/50 rule applies here again.

Simply giving the Initial estimates for the complete Product Backlog containing stories and Epics, without knowing the quantum of work (scope) and which is liable to change in due course, is not going to serve any purpose. Yes, it can serve as a budgetary time for stakeholders to get the rough idea about its tentative release, which will definitely change.

Anup

Posted By Justin on 14 Apr 2014 02:37 PM
So the PO's date is fixed but not the scope? If your team has a constant velocity then you should be able to give him some dates, but remember that your estimates are not supplied in hours. They should be supplied in story points or however you like to work, but the point is that they are not time based.

If you can estimate the epic and its low on the value scale then I think go for it. If its impossible to estimate but is high in value then you should split it up accordingly. If its middle of the road then leave it as an epic. 20/30/50 rule applies here again.

I’m afraid this would give the customer a misrepresented idea of the project no?
Let me rephrase the context again:
The customer (PO) is new with scrum. He has heard from the theory that the scope will/can eventually change once the increments are reviewed, but from a ‘supply and demand thought’ he wants his all initial items estimated.

Posted By Anup Saxena on 15 Apr 2014 02:58 AM
Simply giving the Initial estimates for the complete Product Backlog containing stories and Epics, without knowing the quantum of work (scope) and which is liable to change in due course, is not going to serve any purpose. Yes, it can serve as a budgetary time for stakeholders to get the rough idea about its tentative release, which will definitely change.

Anup

I know the scrum theory, but how would you convince a new customer

You said that your company has adapted scrum has their methodology right?

So when your customer chooses your company, they should respect that your company is being agile. It’s a bit strange if your company changes their way of working just because the customer is not used to it?

This is the coaching part right? Explaining your customer the benefits of keeping the scope variable and convincing them to accept that change will happen along the way so the initial estimate is purely just a forecast, but will eventually change.

The content of the Product Backlog is "Product Backlog Items", not user-stories or epics.

For me, an epic is "just" a big user-story, but not INVEST yet.
We do estimate every PBI, but since the epics are big by nature, the teams estimate them with big planning-poker values (>20), wich is accurate enough for the release planning in order to "feel" the weight of the initial product backlog, for us.

> Does the team estimate the epics? Or do they need to spend time making it all smaller
in order to give an estimate?

Both. It's a false choice. As Olivier has just pointed out: "The content of the Product Backlog is 'Product Backlog Items', not user-stories or epics". So whatever PBI's are on the Product Backlog, they must be estimated (or else the backlog will not be well formed) and they must also be refined further so that better estimates can be given. Bear in mind that backlog refinement is an ongoing process in Scrum and not a discrete event.

> Let me rephrase the context again:
> The customer (PO) is new with scrum. He has heard from the theory that the scope
> will/can eventually change once the increments are reviewed, but from a ‘supply and
> demand thought’ he wants his all initial items estimated.

He's right, and it's perfectly reasonable for him to expect a Product Backlog, no matter how immature it may be, to be sized. If a PBI can't be sized then it must be refined further so it *can* be estimated and included in a properly formed backlog.