Scrum is all about rhythms. Teams that are successful with Scrum establish a sustainable cadence for collaborating with each other. Each of the sprint ceremonies help us move toward our goal, and remind us what’s coming next.
Scrum is pretty straightforward about how to establish the right rhythms for the team, but organizing your work as a product owner is a little murkier. You know that sprint planning happens every two weeks, but what do you need to do to prepare? Your team does backlog refinement for an hour every week, but how far in advance do you need to start working on stories to make that meeting worthwhile?
In this article, I’ll share the rhythms that have worked well for me as a product owner. The Scrum ceremonies act as a trigger – a reminder that there’s something I need to do. I’ll organize this article by those triggers, and we’ll work our way backward to see what we need to do to prepare.
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.
If you don’t know, I’ve got some opinions about Scrum, the Product Owner role, Backlogs, and User Stories. I’ve written a book about Product Ownership and I spend a great deal of my time up to my eyeballs in stories and backlogs at various clients.
One of the things that frustrates those clients is that there are very few “prescriptive rules or firm guidance” when it comes writing stories and crafting Product Backlogs; in many ways, it’s more art than science. It’s also a practiced skill that gets better the more you actually do it—of course as a team, which is also true of agile estimation.
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.
