Breaking down the Epic Stories

I recently attended a course through CollabNet earning me the title "Certified Scrum Product Owner".  I found the course to be an excellent refresher on "Agile - Scrum" practices plus I learned a few new bits specific to the role of Product Owner.

An important piece that I took away from it was a series of strategies to use when attempting to break up "epic" stories.  For those less than familiar with this, an "epic" story is a story that has been sized by the team and has been deemed to be very large and/or very complex.  Epic stories typically have 2 main characteristics.  They have a large amount of uncertainty and risk plus they are usually lacking in detail.  When a team works to break down these epic stories, they often find that much more detail is put in to the resulting sub-stories and they end up being much smaller and much more manageable.

All this explanation is great, but how do you go about breaking these large stories up in to manageable bits?  Well, I invite you to read on...

Separate the UI from the "Plumbing"

Many stories produced by the Product Owner or the customer focus on a complete, tangible feature (or feature sub-part).  Often these stories contain both front end (user interface) and back end (plumbing) components.  Separating these out helps to reduce the scope of the story plus it results in something individual team members can do in isolation.

Separate by Operating System or by Browser

Stories can be separated to target a specific operating system or architecture initially and then be re-worked to include other architectures at a later time.  For web applications, targeting the most common browser first may be the way to go.  This provides the benefit of ensuring the feature is correct (as verified by the customer) before adding the complexities of ensuring the feature is cross platform compatible.  The other benefit is that the majority of the effort will be placed on the initial implementation leaving a much smoother path when adding support for the other architectures.

Separate based on "C.R.U.D." (create, read, update, delete)

This should be an easily identifiable split but when a team gets deep in to story creation, the strategy may not be so obvious.  Large stories encompassing all or part of these (create, read, update, delete) should be split out focussing on each one of these tasks.  This type of separation benefits the team in that the developers can address each one quickly allowing Quality Assurance the opportunity to test the code sooner.  Earlier is better since it keeps all team members busy and keeps the customer up to date sooner.

Separate based on Role

Some features in their original description may cover a variety of user roles.  These can present themselves in the form of a "first time user" or an "advanced user".  Breaking down stories to cover each of these in isolation will help to clarify a story plus it provides the benefit of focussing on the unique characteristics of a particular role.

There are many strategies that can be used to break down epic stories.  I have listed just a few that I find particularly useful in my daily grind.  I hope they become useful for you as well.

--Ken