December 28, 2016
Well-Written Scrum Stories
—The stuggle of writing good user stories in mixed environments.
I work in a domain where Stories in the sense of Well-Written Scrum Stories
don't always work well. Think this is heresy? Read on.
My domain involves the construction of a system. Part of my team's responsibilities include writing software for business logic but it also includes writing software for control elements within the system. For example, we might be asked to integrate a new sensor into our application and that sensor might affect the user's work flow or we might integrate software in the support of mechanical elements (such as motors).
Stories for the sensor integration typically don't sit well with me. The reason for this is that I emphasize user value for my stories. In simple terms, my customers won't pay a sensor. They will pay for the utility provided by the work flow change that the sensor enables.
My emphasis on user value has worked well in other domains. I worked on the integration of Cilk Plus
. We were able to define stories that embodied user value. For example, one user story included the introduction of a for-loop supporting parallelism into the compiler and subsequent stories included the introduction of different stepping increments in the for-loop.
My current domain doesn't have that luxury. Or at least I haven't mastered this domain to that level.
The best description I've seen relating to my problem with stories in my domain comes from Bertrand Meyer. In Agile! The Good, the Hype and the Ugly
, he describes how stories are not useful for describing situations with multiplicative complexity. That is things where all of the key elements of a system must be taken into account at the beginning.
So I live in a world where I use user stories focusing on user value for the business logic level and use another solution to handle the multiplicative complexity of the system. The other solution currently relies on traditional methods for requirements and design.
In effect, I am liberal in what constitutes my product backlog. It's not just user stories.