Around mid may 2020 an investigation found that 55% of companies planned to increase the use of of agile in the following 12 to 14 months, which implied an increase of 13% with respect to the original poll that had been completed 5 months before. 43% said that their boost to adopt agile methodologies had grown in the last 90 days, and 15% that it had increased considerably. 33% pointed out that the adoption of agile had expanded in the last 90 days to help manage teamwork in a remote and distributed context.
Now: as detailed in this article, one of the practices becoming more common is to defragment the assignments of the agile team in a hierarchy which includes these ranks: epic, characteristic, user history and task. This hierarchy was popularized in virtue of the use of the scaled frame Scaled Agile Framework (SAFe), which according to a study by KPMG consulting carried out last year, was being applied in 19% of the participating companies. But, as well, other teams that never used SAFe are employing the same structure, to offer technology services and other kinds of works.
Works included under the range of epic produce great valuable products, or great valuable changes in product. It breaks them down into smaller pieces of value, so it can offer solutions to its customers before expecting a great solution in the end.
On their part, characteristics break down into high value stories that, according to their definition, should also add value in production – something which happens faster than building a new complete characteristic.
Nevertheless, the author of this note alerts that the way in which agile teams break down work in an epics hierarchy, characteristics and stories, there is a hidden anti-pattern which we need to reverse: “Teams utilize agile tools to manage epics, characteristics, stories and tasks. But, very frequently they use them to articulate a new structure of work breakdown (WBS), instead of a values breakdown (VBS)”, they point out. WBS is about the traditional and common practice of project management of dividing tasks into smaller parts, which allows teams to estimate times and costs for its finalization. VBS, on the other hand, is centered on the delivery of products and sub products, not in tasks and sub tasks. Given that the thought of WBS results in “stories of poor users”, the author highlights the need for a critical change in thinking, which in essence should evolve from project management to product delivery.
Changing the chip
In the note we recommend, the author explains how to make this change. He proposes a series of exercises to “change the chip”. Why? “Because many teams use the three ranks logic: epics, characteristics and stories – as containers for big tasks, medium tasks and smaller tasks, which leads to badly written user stories”, he says. And even if this answers to several reasons, in the context under review, the key would be in that they are treated like elements of work, and not elements of value: “WBS has been used to plan the job of software solutions development for a very long time, being this the reason why it is profoundly rooted in our “muscle memory”. And when we were driven by projects, this was a great technique”, says the author. And adds, “But with the movement of the project culture towards the product culture, this technique no longer works well. Today, we have to think in terms of product delivery”
In a VBS, epics, characteristics and stories are the same: value delivery. Only that each one has different rules and syntaxes because they entail a different risk level.
Epics have higher risk; characteristics are less risky and stories, even less. Besides, each epic, characteristic and story creates or modifies a product: epics are values that will be delivered or will be ready for production in more than three months: characteristics can be delivered in less than three months; and stories can be delivered in less time than a sprint can.
The conclusion is that epic versus characteristic versus story is simply a first level assumption on the size of the effort, to offer value. In this way, each time we go from a WBS to a real VBS, agile teams can easily inform about the value delivery.
In brief, the note points out that many people see their agile work management tools as an epic, characteristic and story hierarchy. And the muscle memory of a WBS is so strong that there is an overlapping of this work breakdown structure in the containers of epic, characteristic and story. The proposal, instead, is to focus on products, sub products and value delivery. Refactorizing existing delays, separating tasks from value. And to think in the hierarchy of epics, characteristics and stories as nothing more than a first time estimate. To further analyze this perspective, we invite you to read this article.