Earlier this week, Renee Troughton wrote about the confusion that sets in with the various definitions used to describe requirements in agile development:
Epics, Themes, Stories, Features, MMFs, MVPs, MVFs, MMRs, Goals, Objectives, Tasks, etc.
As I read her post, I caught myself thinking about whether the different distinctions really help me write better software.
Meanwhile, Renee points out that people don’t always agree on the distinctions. Go figure, with so many ways to describe them.
If producing software is our main objective, then we come up with distinctions to help communicate and coordinate that production… except that confusion over common terminology actually makes communication harder.
Shifting paradigms in science
Now, in scientific paradigms (and I don’t pretend that writing software is as scientific as it is creative), we describe reality in a theory that holds up – until it doesn’t anymore.
When we discover it doesn’t hold, we propose a new theory that takes care of our past observations as well as what we now observe. In The Structure of Scientific Revolutions, Thomas Kuhn writes about “normal science” and how paradigm shifts take place.
In science, we move back and forth between:
- Trying to show that our current paradigm is satisfactory for the problems of the day and
- Trying to claim that the need for a new paradigm is upon us.
We once believed in miasma (bad air) theory as the cause for the spread of cholera and the Black Death… and then we learned about germs. We once thought we could store electricity in the water of a Leyden jar… and then we learned about capacitors.
During the transition from one paradigm to the next we just can’t explain some phenomenon we observe in terms of the old rules. We start to invent terms to fill in the gaps left from our previous understanding… and people get confused for a while.
Agile distinctions are metaphors
In the world of agile, however, we keep piling on the distinctions, without producing a truly standard lexicon. We aren’t in the middle of a paradigm shift – the problem is that our vocabulary is full of metaphors that make the distinctions weak.
Though metaphor is usually intended to help produce shared meaning, when the metaphor itself is not shared between people and we base our language on that metaphor, we leave meanings open to each person’s interpretation of the metaphor in question.
We can’t debate the “rightness” or the “wrongness” of a metaphor that isn’t held by others the way we like or with the precision we intend. Or rather, we can only debate dogmatically. (And we certainly do that.)
Is an Epic bigger than a Theme? Or is it the other way around? Who says so? If you encountered the confusion Renee writes about, your answer could be “it depends who you ask,” or simply “it depends.” Of course, if your answer is “who cares?” then we are in the same camp. Read on.
Back to basics… it’s the software
Renee proposed a “library” metaphor that works just as well for me as the collection of terms she cited in her post. Remember that the main goal is producing software?
What it comes down to for me is that I don’t really care about whether the Epic or the Theme is bigger.
As I am sure you are aware, Newtonian physics was the answer before relativity… which was before quantum mechanics… and for most people Newton still works just fine.
We’ve had user stories as long as we’ve had XP. Now, Epics and Themes are helpful tools in planning bigger stories, but the skill of the project coach and team to ship the software takes priority over the nuances in terms.
Getting engaged in dogmatic debates over which metaphor sounds right to us is more like miasma. (Bad air, remember?) I’d be just as happy with invented words if they helped us communicate.