I recently received the following email from Dwight Kingdon at Mindtree:
I’d appreciate your thoughts on “Just in time” Product Backlogs. I’ve recently run across a couple teams where the Product Owner is not populating the Product Backlog with user stories until just before they will be worked on. They have themes and epics, but do not break them down any further until a new sprint is about to start.
My thinking is that a robust Product Backlog of “potential” user stories is a good thing, as long as the stories there are viable, and the team doesn’t spend too much time getting into the details until they have moved up in priority to where the value is high enough that they will be worked on soon. It seems to me that having user stories sit in a Backlog until they either move up in priority or get deleted (due to lack of value) is not harmful, and gives the team a preview of potential future work that they can keep in the back of their mind.
What do you think about a “robust Backlog” versus a “lean/just-in-time Backlog”? Thanks in advance – I look forward to hearing your thoughts!
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—
I have a confession to make. I've been podcasting with my friend and colleague Josh Anderson on the Meta-Cast for over 5 years. And I've been loyal to it.
But recently I was invited to chat with two follow podcasters. So I cheated, just a bit, and had a great time chatting with these folks.
I thought I'd share links to those 'casts here, just in case you're interested in the conversations. I also recommend you pay attention to the two podcasts as they are well done and incredibly relevant.
- Deliver It podcast with Cory Bryan, we chatted about Product Ownership, imagine that?
- Mastering Business Analysis podcast with Dave Saboe, we again chat about Product Ownership. But this time with a twist towards Business Analysts.
What were the topics you might be asking? Scrum Product Ownership
I hope Josh understands...
Stay Agile my Friends!
Bob.
In a recent article on AgileConnection, Allan Kelly wrote the following about the timing of writing acceptance criteria (acceptance tests) for user stories:
The Right Time to Define
I am frequently asked, “When should we write the acceptance criteria?” Sometimes programmers resist giving an effort estimate for a story unless they can see the ACs—sometimes detailed ACs, at that. However, there is little point in POs (and testers) spending time on ACs until stories are about to be scheduled. After all, if ACs take hours to write and the story is not scheduled, their time is wasted.
Also, if ACs are added but then the story doesn’t get scheduled for a year, by that time the story and the ACs may have changed. Because old criteria are in place, it can be easy to overlook these potentially important changes.
Chris Waggoner is a friend and colleague of mine. He is a CSC, Certified Scrum Coach, and a very experienced agile practitioner.
He sent me the following snippet in an email that I wanted to share:
"If Agile is a team sport, then the product backlog is the ball." - Chris Waggoner
I'm trying to get a group of PO's to realize that they should not attempt to complete a product backlog on their own but they should seek help at every phase of grooming stories and massaging the backlog. On the flip side I'm trying to involve teams who believe it’s the Product Owners responsibility to bring them a completed, ready to consume story that they to are responsible for the completeness of stories and the state of the backlog. This metaphoric phrase above came out of my mouth and it made sense to everyone once it did.
Chris Waggoner, CSC
Managing Consultant | SolutionsIQ
It was unsolicited, but nicely aligns with my own thinking.
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.
