Two of the INVEST criteria for user stories are that they should be negotiable (meaning the details can be adjusted) and independent (of each other). But if we write the stories in difficult language those two criteria become challenging.
Some time ago I was discussing stories which were described in very technical language. This made them all seem important and seemingly essential. In order to understand them one needed to know not the product, but the product’s internal technical architecture. Therefore it was difficult to challenge and discuss the details of each story, or even whether any of them were needed right now. This was particularly problematic because we wanted to involve a wider stakeholder group who weren’t as close to the work as those in the room. If some of us in the room had difficulty understanding the stories, what hope did anyone else have?
So I raised my concern, and we debated the stories and looked for better ways to explain the work. In the end we didn’t divide the work up any differently, but we did change the wording of each story—it turned out that each one did deliver some end user value, even though this didn’t come out in the original descriptions. This outcome pleased everyone, as it entailed minimal work and it made further conversations much more practical.
The technical language had made the stories seem neither negotiable nor independent. Their descriptions were pretty impenetrable, so a conversation around prioritisation had become almost impossible. Just by changing the language we made them more meaningful and we gave ourselves more flexibility and control.
niksilver.com 