I periodically do a coaching circle as a service to our agile community. I invite anyone to it and it’s free. Think of it as a Lean Coffee format discussion with folks looking for coaching advice.
This question came up the other day:
I'd like to hear how your teams handle spikes - do spikes have acceptance criteria - yes/no? Do spikes have story points yes/no?
And it generated quite a nice discussion around the idea of spikes. And it made me think about whether I’ve ever written about them before. I was shocked to realize that I really hadn’t done a deep dive into my thoughts on spiking. Well, here goes nothing…
I teach quite a few teams about User Stories. Most struggle with the concept, at least initially. One of the key challenges for many is the notion that stories are iterative. That you visit and refine them often, instead of the “once and done” view that we have for traditional software requirements.
Part of that revisiting is reinforcing the collaborative nature of the stories. The nature that says they are “intentionally incomplete” in order to encourage conversations around the story. Remember the 3’C’s from Ron Jeffries: Card-Confirmation-Conversation, with conversation being the most important ‘C’?
I thought it might be helpful to go through a life-cycle example of how stories morph and change as they approach an execution-ready state. So here goes a somewhat contrived example—
The user story has nearly become the ubiquitous requirements artifact in agile contexts. So much has been written about the user stories, their format, how to write them, the associated acceptance tests, and more.
As for acceptance tests, we’ve moved beyond writing them to articulating them as “executable tests” in tools such as Cucumber and Robot Framework.
All of this evolution has been great, as is the focus on the collaborative aspects of the user story.
But I’m starting to see something troubling in my coaching travels. I think we might be focusing too much on the user story as an agile requirement artifact. Instead, we should be taking a step back and considering the user story as a much simpler communication device.
That is simply as STORY, and much less as a written story, but more so as a story that is told…face-to-face.
If you’ve any experience in agile approaches for software development, one of the common arguments surrounds documentation. Mostly it centers on software requirements, but it also extends to other forms of documentation, for example design or user centered documentation.
Many agile teams struggle with documentation. My experience aligns with folks leaning one of two ways:
- Either they continue to write requirement documentation (and literally ALL documentation) as if they were still operating in a Waterfall environment, or
- They write user stories that are so terse as to be hardly useful in describing the customer’s expectations. And they often stop writing anything else.
In other words, they go to the extremes of documentation instead of finding a healthy, lean, and communicative balance. One of the reasons for this seems to be our view of documentation as being the sole “repository” for product and team knowledge. While that’s true, I also like to remind agile teams that there is another viable form or place for that knowledge – which is the teams’ memory. Since many of the agile ceremonies are whole team events, I like to ask teams to use their collective memory as part of their product information and knowledge archive.
I presented at a local professional group the other evening. I was discussing Acceptance Test-Driven Development (ATDD), but started the session with an overview of User Stories. From my perspective, the notion of User Stories was introduced with Extreme Programming as early as 2001. So they’ve been in use for 10+ years. Mike Cohn wrote his wonderful book, User Stories Applied in 2004. So again, we’re approaching 10 years of solid information on the User Story as an agile requirement artifact.
My assumption is that most folks nowadays understand User Stories, particularly in agile contexts. But what I found in my meeting is that folks are still struggling with the essence of a User Story. In fact, some of the questions and level of understandings shocked me. But then when I thought about it, most if not all of the misunderstanding surrounds using user stories, but treating them like traditional requirements. So that experienced inspired me to write this article.
I’m sorry but I need to vent. I’ve been encountering these
patterns a bit too often lately and I just need to get these thoughts off my
chest.
The patterns are these:
- Organizations and teams consider it the Product
Owners role/job to write every aspect (word) of every User Story. And,
if the stories aren’t “complete enough” the team kicks it back to the Product
Owner to do a better job.
- User Stories are too robust. I’m being kind
here. The Product Owner / Analyst writing the story writes a complete
requirement (pages, all information) before ever showing it to the team.
From my perspective, these are both agile requirement
anti-patterns, you shouldn’t be doing it this way, and I’ll try to explain why.
In both cases, I think it goes against some of the very core principles of the
agile methods. It’s not changing your Waterfall views and while, you’re saying you’re
agile on the outside, on the inside you’re still handling your requirements the
same old way.
