When you cracked the lid on the Spring 2015 release of VersionOne, you may have noticed that the Epic asset has gone missing. Well, the asset itself isn’t actually missing – but what exactly did happen to it, and why? And what’s all this “Portfolio Item” business?
A Little Bit of Background
The term “Epic” was embraced several years ago by the agile community to simply describe a “big story” – one that is too big to complete in an iteration. As the leader in Agile ALM software, VersionOne adopted that same definition.
Over the ensuing years, the community has experimented, inspected, and adapted techniques for scaling agile. In doing so, it has learned to tackle things that not only are bigger than stories, but also larger than those “big stories”.
So the concept of “big stories” expanded to “really big stories, that can be split into big stories, which can then be split into stories.” Some have taken that even further, and use epics to include “really really big stories, that can be broken down into really big stories, that can be…” Well, you get the picture.
What We Noticed
As our customers adopted the flexible use of the epic, VersionOne’s capabilities evolved with you. We enabled you to designate epics of different types, size them, associate them with their own kanbans, view their progress on a timeline, and so on – all while maintaining cohesion within an epic hierarchy.
Still, in practice, we observed a couple of things:
- Different organizations have different levels of decomposition/aggregation above the level of the user story (some have a couple, others have three or more).
- Different organizations use different terminology for those various levels of decomposition.
It is also true that organizations often have their own definitions for the term “epic,” or don’t use the term at all. Mix in the fact that some widely-adopted frameworks have assigned very specific definitions to the term “epic,” and it is no wonder that referring to a base asset as an “epic” got to be confusing.
How We’ve Responded
Enterprise agile practices have evolved significantly, especially over the past two-three years. The concept of the agile portfolio has become broadly accepted as a legitimate means of organization in enterprise-wide agile software delivery. Along with this, it is recognized that a flexible means of connecting business strategy to execution and delivery is needed.
Although this flexibility has existed with our Epic asset for quite some time, we decided that continuing to call it an “epic” would not be consistent with how agile is evolving. That’s why we’ve changed the name of the Epic Tree structure to the Portfolio Tree, and an individual item in that tree to Portfolio Item. We believe that this better characterizes what that asset signifies: a large item of some type and some scale, within the scope of a portfolio, which represents something larger than a single team’s user story.
Portfolio Item also conveys a more appropriate level of abstraction. You will no longer have to deal with the awkwardness of saying “Epic of type Epic” and “Epic of type Feature,” etc. That was like saying “Apple of type Apple” and “Apple of type Banana.”
Through the Portfolio Item’s Type attribute, you can configure VersionOne to have Portfolio Items of any types that match the way you systematically break down your initiatives. For example, you can have a Portfolio Item of Type ‘Epic’, Portfolio Item of Type ‘Feature’, Portfolio Item of Type ‘Sub-feature’ – whatever is appropriate. This is more like saying “Fruit of Type Apple” and “Fruit of Type Banana.”
We believe that this adaptation, together with the improved Portfolio navigation, Strategic Themes, and enhanced visual differentiation of Portfolio Item types, gives you a more flexible, less confusing way to describe and visualize how your organization’s investment strategy is being realized.
Let us know what you think!
Note: We acknowledge that, for some organizations, the old terminology worked just fine and there can be a strong desire to stay with that vocabulary. We hope you’ll give consideration to the new terms, but if your organization really wants to revert to the old terminology, there is a simple way of doing so: Just have your system administrator make the terminology override in the System Configuration section of Administration.