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.
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.
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,
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
Become a MOZARK certified Appium tester and win gift vouchers worth INR 15k. Participate in MOZARK’s Global Mobile app Testing Contest, QAppathon now!
The contest is free to register, all you need to do is:
• Sign up to MOZARK QAppAssure
• Write an Appium script to measure the Home page load time of your app.
• Run the script on at least 10 devices across the QAppAssure device cloud.
• Ensure a minimum of 50 test runs.
• Send in the logs and a brief description of your test methodology to [email protected]