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.
In 2009 I first published Scrum Product Ownership. In 2013, I followed it up with a second edition. The book has been a popular read for those who are looking for a solid overview of what it takes to be a competent and craft-focused Product Owner.
Here’s what a new Product Owner from Spotify had to say about the book:
“I was recommended your book “Scrum Product Ownership - Balancing Value from the Inside Out” by senior colleagues at Spotify as the one book to read when new to product owning. After recently finishing reading it, I fully agree and will keep recommending your book to anyone getting started as a product owner.
I just wanted to say thank you for making the start of the ride less bumpy and for great advice that I will keep returning to as I gain experience.”
I share this because it helps to set the stage for this article and where my inspiration lies.
I’ve been a Mike Cohn groupie for as long as I can remember. Mike has written, what I consider to be, three of the seminal books on agile approaches for software development. I’ll leave it as an exercise for you to lookup the books, but he’s really been one of the leading voices on how to “do Scrum” and “do Agile” for an incredibly long time.
I took my CSPO class from Mike and Ken Schwaber, just so I could learn from two of the “masters” in my agile journey. And when anyone asks me for a recommendation of an instructor for a CSM or CSPO class, Mike is at the top of my list. I remember sending all of our potential ScrumMasters at iContact years ago to Mike’s CSM classes. My logic was, that if we were going to spend the money, we might as well go to the best.
Now that I’m looking at the start of this article, I’m almost embarrassed as to how much of a Mike Cohn groupie I am. But I digress…
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 wrote an article a few months ago about sprint reviewing the “hard stuff”. It was inspired by an engineer who asked me (challenged me) about demonstrating more back-end, embedded, non-UI, infrastructural work at the end of Scrum sprints.
His general take was that it was:
- Hard to figure out how to demo the “stuff” they were delivering, and
- The components didn’t lend themselves to demonstration (in simplistic terms, they didn’t have a UI)
I pushed back a bit in the article, trying to encourage him to demo “something” and not “go silent” for too long.
I honestly believe that having high-energy and high-impact Sprint Reviews truly differentiates high-performance agile teams and organizations. It's very much of a "Show Me the Money" moment for the team. It allows the team to be transparent and demonstrate their results. It allows the organization to provide feedback. And it serves as a progress baseline / milestone so as to measure progress towards established goals. And finally, it should be cause for "celebration".
In many ways, agile delivery is about Earned Value, and EV is demonstrated one sprint at a time.
This update is from the STP conference I’m attending in Denver the week of November 3, 2014. Software Test Professionals is a conference mostly focused towards testing, so the slant of all of the talks is that lens or perspective. That being said, the agile topics are by definition broader and more whole-team centered.
I just attended a session by Jeff Porter where he was exploring agile practices in a talk entitled: Agile – Where the Rubber Hits the Road.
Now let me start by saying that I liked Jeff’s talk. It was very pragmatic and practical. He simply shared what they were doing at FamilySearch.org. Practitioner reports like this one truly enhance the state of practice in the agile community.
Introduction
There are several terms used for it within agile contexts. Sometimes you hear:
- Done
- Definition-of-Done or DoD
- Done-Ness Criteria
- Acceptance Criteria
- Release Criteria
Sometimes you even hear it repeated, as in: This story isn’t complete until its—“Done…Done…Done”.
Apparently the more “done’s” you have, the more emphasis there is on completeness. Although I don’t think I’ve heard more than four “done” used in a row.
A coaching colleague of mine approached me with some questions for a university class he was asked to do on Product Ownership. I got the impression the lecture was for a Software Engineering class that was being introduced to Agile Methods in general and the Scrum Product Owner role specifically.
Here are the five questions and my answers:
George Lawton, from the ServiceVirtualizaton.com blog asked me for an interview. He was generally interested in KEYS to agile testing maturity. Something Mary Thorn and I have been “yacking” about for quite some time.
I thought it might be interesting to share his questions and my answers. It will even be more interesting to see “what parts” of my answers make it into his blog ;-)
Stay agile my friends,
Bob.
