I'm reading Mike Cohn's book about Agile estimation. At the same time I have a release planning in couple of days.
It's going to be 6 months (12 sprints release). We have the ideas about what needs to be implemented, but they are all large, like themes. Mike Kohn suggest to split all of them into the stories and estimate stories.
It will take couple of days and we don't need such precise information at that point. For example: we will have to implement error logging. I don't need to plan for the exact levels of errors, etc. yet. We will need to implement Roles, but I don't need a list of roles and their permissions at that point.

Has anybody tried to estimate themes/epics (I understand that epics are usually too big to estimate) during release planning?


1 Answer 1


Go for it but:

Don't story point estimate your epics and assume that those story points will later be equal to story points on actual stories of the corresponding stories belonging to each epic.

Or t-shirt size your epics instead and putting a priority on them like high, medium, low. An XXL, high priority epic is probably the first epic you actually want to invest your time into breaking up into stories during your first round of release planning.

For projects that span 12 months +, it can be kind of painful (in terms of time) and also misleading to think you can and should break everything down into a story during initial release planning.

In Agile, release planning is continuous. If you are trying to plan out all of your stories during initial release planning that sounds kind of waterfall to me. Instead, take your top 2-3 epics and break them into stories that can be story pointed.

Once you have 2-6 iterations of stories with estimates derived from your epics take a break with release planning and see how things go. But plan on returning to release planning every 1 to 2 iterations later so that you keep your product backlog up to date and that actionable stories are always ready for each iteration.


How do I deal with projects where a hard, external delivery date has been promised to the customer that is so far out in the future and beyond the point where precise story point estimates can be reasonably provided?

  1. Accept the fact that your project was not conceived as an Agile project and that the customer was sold a product, rather than an Agile team capable of delivering value to the customer.

  2. Swag your epics, personally I like to work with my teams to swag in terms of iterations. Will this feature take 1,2,3,5,8 etc iterations to deliver? Can this feature be delivered parallel to other features requested? What are the max number of features we want to limit ourselves as a team to working on in an iteration?

  3. Come up with a visual (not visio necessarily) product roadmap that lays out which epics/features will be delivered and in which order. For big projects, your timeline can be pretty vague. I like to bucket features into months or even quarters.

  4. Now I have a rough timeline and duration for each feature being delivered and a very waterfall-ish plan that I can present to managers to give them that "precise" plan for meeting their delivery goal.

  5. Here's the hard part; set the expectation with managers and the customer that the roadmap IS NOT a commitment. It is a rough estimate of how things will go and one possibility for how the team could deliver. Reserve the right to update and communicate changes to the roadmap to stakeholders.

  6. Now here's the hardest part: sell Agile. Let managers and customers know that 1) its ok for the customer to change their mind, 2) the more customer face-time the team gets on a regular basis, the better the outcome will be, and 3) build trust and transparency between the customer, management, the team so that in the future the customer doesn't need a waterfall roadmap since they know they are not buying a project, but an Agile team instead.

  • 1
    I use this kind of approach. Now we are going to do 3 release estimation and this is going to be big delivery and there is fixed delivery date. So it needs to be precise and it seems there is no way except detailed planning.
    – Ruslan
    Jan 13, 2015 at 19:54
  • 2
    I hear what you're saying Ruslan. My current employer also does big bang projects that span 1-3 years but have fixed delivery dates. It's an every day struggle to run a true agile project when your customer and sales reps still make waterfall promises and think they can commit to a date 1+ year in advance.
    – WBW
    Jan 13, 2015 at 21:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.