The role of epics in agile analysis
Some time ago, Alexandre Klaser and I presented the Goal-based Prioritization framework, which describes a table where the columns are hypotheses to be tested and lines are levels of refinement. We were asked about the role of epics in this framework and that got me thinking. My first thought was that epics don’t have a role to play at all.
But then again, sometimes they do. I believe there are scenarios where the concept of an epic makes sense (e.g.: when a story is found to be too big – in this case, we can make it an epic until we split it into smaller stories), but I do not like the idea of writing epics and then dividing them into stories. When we do that, we are coming from a presumed set of functionalities, and describing it as stories.
When epics are used this way, we must assume that these requirements are already known and are simply being put on paper. I call this the Inductive Model. This model starts from a problem, to an imagined solution to the problem, which is divided into a set of features described by epics, and these epics become stories.
Problem → Solution → Features → Epics → Stories → Working software
This sequence assumes that the best solution to the problem is the one initially thought of, and that the software that represents the solution (and therefore solves the problem) will be obtained when all features are implemented as described in the epics (and consequently in the stories). So far, so good. But how do we know that all the features described are necessary to provide the solution? And more: why are we so sure that the imagined solution actually solves the problem? And finally, how is the problem in question related to the business goals?
The Inductive Model is appropriate in situations where the cost of changing your mind is very high, so we invest a lot of time specifying what should be done to make sure we are doing the right thing. Luckily, today’s software is not limited by the ability to change it (if it ever was). On the other hand, the inductive model can lead to an uncontrolled increase in the scope, because there is no opportunity to validate how much is enough. This leads to a temptation of just adding all features that will ensure that the problem will be solved. Even in mature teams, the consequence of this previous analysis is a full backlog.
Generative vs. Inductive
What strikes me as odd is that the Inductive Model prescribes what should be done as opposed to the result to be obtained, and this results in a "closed" solution that leaves no room for discovery and innovation. What we propose with Goal-Based Prioritization - the way we use the project goals to derive progressively more rounded-up solutions - is a "Generative" model of analysis. The Generative Model seeks to make the business goal "generate" the user stories that will fulfil it. To do this, we assume that there is a problem to be solved, and come up with assumptions of what we believe will bring us closer to meet that goal, thus:
Objective → Hypothesis → Stories → Working software
The first thing you might notice is that this is a beeline for working software. This does not mean we would deliver the same volume of user stories in less time, but that the work is done in smaller increments and validation for that specific goal happens earlier. Another benefit is that it assumes very little, since it does not presume that there is a correct solution.
Someone may wonder if using this model could ever deliver the “required” functionality, given that they are not formally described. It is impossible to answer this without another question: Who "requires" that functionality? The analyst? The manager? The only person who can legitimately need some software, is the end user of that software. The design team should meet only the needs of this user, so any "required" functionality for the project team is solely the opinion of the staff as to what would meet the user's needs. No effort of analysis, in my experience, is enough to identify it. Working software is the best measure of success in this regard.
