Agile. Release planning. Why do I need stories instead of themes/epics

Question

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?

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.

Addendum:

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.