When I first read through this essay concerning story mapping, I was pretty skeptical of the author’s meaning. The author claims, as well as implies, that stories are superior to requirements because they open up the amount of innovation that people can have with regards to creating. Specifically, aligning everyone on a story is easier than aligning everyone on a document. I find this claim actually quite hard to believe.
In most cases of groupwork, I’ve always worked through design processes where we’ve aligned on the target or goal and then ideated out particular features. This means that the design process would go from a very top-down approach. We would know exactly what we wanted, and we would know what steps to take to get to there. This approach would often meaning a well-flushed out document in which members would pass around to all align on the same output. In reading this essay, I was pretty shocked to see the author consider the use of requirements and documents as a whole to be obsolete.
It is true that stories aren’t requirements, but I think a fundamental mistake that the author is making is missing the implication that stories will create requirements.
I definitely agree with the author’s last recapped point, however. “Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get from what you choose to build.”
If we are to be the most productive, it means that we should maximize quality and impact, not just amount produced.
