I was in a Backlog Refinement meeting the other day and you would have thought I was in divorce court where the parties were negotiating (fighting for) everything.
Each time the team asked clarifying questions around a user story, the Product Owner would begrudgingly answer. It felt like they thought they were wasting time trying to explore the story.
It was clear that what he really wanted was…an estimate.
So the team felt the pressure and stopped asking question. Instead they went immediately into Planning Poker for each story. And as you might expect, the estimates were sort of…all over the place.
Often agile organizations take the position that the Managers, Leaders, or the Scrum Masters are responsible for keeping the team focused and energized towards their work. And yes, these roles can play a part in keeping the teams passion and energy focused towards doing great work.
But I’ve found that another role can really make a difference here as well. One that is rarely suggested for this sort of nuance. That role is the Product Owner.
To make my point, I’d like to share a dozen “opportunities” for a Scrum Product Owner to make a difference within their teams. Is the list exhaustive? Probably not. But that’s not the intent. The intent is to get Product Owners thinking outside the role of backlogs, user stories, and delivery. And instead thinking about ways where they can play a key role in the engagement, joy, energy, passion, focus, and results of their teams.
Yes, I just added another large responsibility to an already overwhelming role. Sorry about that.
I read a wonderful article the other day that surrounded some specific techniques for portfolio management.
Here’s a link to the article: http://www.infoq.com/articles/visual-portfolio-management
I immediately thought of the SAFe guidance for portfolios and just really enjoyed the simplicity and practicality of the approaches in the article.
For example, the article diagram illustrates visually how an organization is moving portfolio items from Idea…to Live or “Cash”. Clearly it’s a Kanban approach, but I don’t believe there is exhaustive analysis (business cases, etc.) for each idea. The board simply radiates the portfolio and each item moves forward based on (1) it’s on merit and (2) the organization determining that it has value.
Jason Tanner is a colleague of mine here in the Cary, NC area. He’s a Certified Scrum Trainer (CST) with the Scrum Alliance, which means he can teach certified ScrumMaster and Product Owner classes.
With that title and role comes a responsibility to stay pure to the “rules” of Scrum and its defined practices.
So, Jason will often argue with me about specific agile practices such as:
- Sprint #0’s
- Hardening Sprints
- Release Trains & Planning
As (1) not being part of Core Scrum, and he’s certainly right about that, and (2) just being plane old bad practices. It’s here that I sometimes push back a bit on Jason, thinking that he might be a bit too purist in his approach and thinking.
But it’s all done in good humor and with respect. Or at least I think it is. But that’s beside the point.
I was reading a post from Rich Mironov that I simply had to share. Here’s a link to the post: http://www.mironov.com/8mistakes/
The title was: Eight Mistakes You’ll (Probably) Make in Your First Product Management Job.
My favorite of his eight items was #6 - Tell engineers how to solve technical problems and #8 – Confuse process steps with market steps.
You’ll want to share this with your Product Managers and Product Owners independent of their experience and role.
Rich is one of the leading voices in the “product community” and well worth listening to.
Stay agile my friends,
Bob.
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.
