We were asked to estimate the effort for epics but declined to do so until it was broken out into stories. Is there any realistic way to accurately estimate the effort for an epic?
Agile teams often use the concept of story points to estimate epics. Story points represent a relative measure of effort or complexity and are not tied to specific time units. The team compares the epic to previously completed user stories or reference stories to assign a story point value. This approach helps in gauging the relative size and complexity of the epic compared to other work in the backlog.
Hey,
To estimate an epic, first, break down its scope into smaller, manageable parts. Identify high-level requirements and desired outcomes. Analyze complexity, dependencies, and risks. Engage stakeholders for diverse perspectives. Use historical data and project experience to inform estimates. Consider team expertise, resources, and external constraints. Employ estimation techniques like story points or relative sizing to assign a numerical value or size. Regularly review and refine estimates as more information emerges.
Thanks
Vivek
Thanks for all the answers. This has been a very useful conversation that I can pass on to my colleagues. I especially like the "rough order of magnitude".
Thanks again --LisaAn
If you think about 1 day to breakdown and estimate an epic - what about making an offer about building a new big e-shop for a customer with around 150 epics. it would take you around 150 days to make an offer.
Sometimes a rough guess is all you can get and this is better than nothing. Of course it would be better to have customer that tells you the budget and trusts you that you will worl as good as possible and deliver as much as possible for the money. But this is not how my life at work currently works.
I know - this is not the way it should be - but sometimes you have to deal with how it is and try to change it. Most important for me is that everybody knows, that a fast estimation ends up in a rough guess that will change in some directions and that you have to take care that it will change in the right direction.
Hi Lisa
I would not recommend attempting to estimate an epic. An epic is something that is going to take a considerable amount of effort and is usually made up of several if not dozens of stories and possibly hundreds of tasks.
It sounds like what is being asked for is more like a Rough Order of Magnitude (ROM) estimate which comes with a threshold of -50% to 200% variability in what is quoted which most managers and up find of little use.
I would stay firm with the team on insisting you break down the epic(s) to user stories and if possible tasks. For a rough estimate and depending on the complexity of your epic a one-day workshop (or less) might be all that is necessary to attempt to estimate the entire epic.
Just some ideas and suggestions. Some great strategies are outlined in Estimating and Planning by Cohn and Cyrstal Clear by Cockburn
Hope this helps,
Chris
As I said: an epic-estimation will be really rough - but sometimes this is needed anyway and sometimes there's not the time to break it down into better estimatable user stories. I agree: my recommendation would also be to break down and take time to get it planned and of course not to feel safe with a roughly estimated epic. For example: Sometimes it is necessary to do a rough (and of course changable) release-plan with prioritized "next steps" and the customer would like to know if he gets a feature this or next year. therefor all epics in a backlog should have a rough guess how long it will take with measured velocity of the team.
What I would like to know:
what was the demand - whatfor sould the epic be estimated? It is (of course) not a good base to start developing.
I don't recommend estimating an Epic for two reasons. First, it's very unlikely that you will be able to articulate an Epic well enough to estimate. Second, and Epic is so large that any estimate would have too much margin for error.
Instead, start creating User Stories for the Epic (or Features, if using Scaled Agile). Prioritize and estimate the Features or Stories, then build Sprints and Releases from there.
An estimation is still an estimation - so there should not be a problem with estimating epics. It's less safe (it's an estimation so you can't be safe anyway) - it's more a guess but sometimes a guess (a rough evaluation) is enough or still better than nothing. It's just importan to let the people know, that it's more a rough guess than a safer estimation.
We always do story point estimation in groomings for stories and sometimes in release planning meetings for epics too. in my opinion for rough estimations on an epic level this estimation game is a fun way to get good results.
Another way to get a clearer picture could be to do a rough guess/estimation on this epic level and add a level of "comfort". let your estimating team tell you, how safe they feel with their estimation. If they feel comfortable with their guess it's more likely that the estimated size will be the real size than if they do not feel comfortable with the estimate.
An estimation is still an estimation - so there should not be a problem with estimating epics. It's less safe (it's an estimation so you can't be safe anyway) - it's more a guess but sometimes a guess (a rough evaluation) is enough or still better than nothing. It's just importan to let the people know, that it's more a rough guess than a safer estimation.
We always do story point estimation in groomings for stories and sometimes in release planning meetings for epics too. in my opinion for rough estimations on an epic level this estimation game is a fun way to get good results.
Another way to get a clearer picture could be to do a rough guess/estimation on this epic level and add a level of "comfort". let your estimating team tell you, how safe they feel with their estimation. If they feel comfortable with their guess it's more likely that the estimated size will be the real size than if they do not feel comfortable with the estimate.
I don't recommend estimating an Epic for two reasons. First, it's very unlikely that you will be able to articulate an Epic well enough to estimate. Second, and Epic is so large that any estimate would have too much margin for error.
Instead, start creating User Stories for the Epic (or Features, if using Scaled Agile). Prioritize and estimate the Features or Stories, then build Sprints and Releases from there.
As I said: an epic-estimation will be really rough - but sometimes this is needed anyway and sometimes there's not the time to break it down into better estimatable user stories. I agree: my recommendation would also be to break down and take time to get it planned and of course not to feel safe with a roughly estimated epic. For example: Sometimes it is necessary to do a rough (and of course changable) release-plan with prioritized "next steps" and the customer would like to know if he gets a feature this or next year. therefor all epics in a backlog should have a rough guess how long it will take with measured velocity of the team.
What I would like to know:
what was the demand - whatfor sould the epic be estimated? It is (of course) not a good base to start developing.
Hi Lisa
I would not recommend attempting to estimate an epic. An epic is something that is going to take a considerable amount of effort and is usually made up of several if not dozens of stories and possibly hundreds of tasks.
It sounds like what is being asked for is more like a Rough Order of Magnitude (ROM) estimate which comes with a threshold of -50% to 200% variability in what is quoted which most managers and up find of little use.
I would stay firm with the team on insisting you break down the epic(s) to user stories and if possible tasks. For a rough estimate and depending on the complexity of your epic a one-day workshop (or less) might be all that is necessary to attempt to estimate the entire epic.
Just some ideas and suggestions. Some great strategies are outlined in Estimating and Planning by Cohn and Cyrstal Clear by Cockburn
Hope this helps,
Chris
If you think about 1 day to breakdown and estimate an epic - what about making an offer about building a new big e-shop for a customer with around 150 epics. it would take you around 150 days to make an offer.
Sometimes a rough guess is all you can get and this is better than nothing. Of course it would be better to have customer that tells you the budget and trusts you that you will worl as good as possible and deliver as much as possible for the money. But this is not how my life at work currently works.
I know - this is not the way it should be - but sometimes you have to deal with how it is and try to change it. Most important for me is that everybody knows, that a fast estimation ends up in a rough guess that will change in some directions and that you have to take care that it will change in the right direction.
Thanks for all the answers. This has been a very useful conversation that I can pass on to my colleagues. I especially like the "rough order of magnitude".
Thanks again --LisaAn
Hey,
To estimate an epic, first, break down its scope into smaller, manageable parts. Identify high-level requirements and desired outcomes. Analyze complexity, dependencies, and risks. Engage stakeholders for diverse perspectives. Use historical data and project experience to inform estimates. Consider team expertise, resources, and external constraints. Employ estimation techniques like story points or relative sizing to assign a numerical value or size. Regularly review and refine estimates as more information emerges.
Thanks
Vivek
Agile teams often use the concept of story points to estimate epics. Story points represent a relative measure of effort or complexity and are not tied to specific time units. The team compares the epic to previously completed user stories or reference stories to assign a story point value. This approach helps in gauging the relative size and complexity of the epic compared to other work in the backlog.