It’s sort of a chicken and egg problem in many agile teams—that is the notion of trust.
- Do you give the team your trust as an organization? Or do they have to earn it over time?
- And if they make a mistake or miss a commitment, do they immediately lose your trust? And then have to start earning it again?
- And is trust reciprocal, i.e., does the organization need to gain the trust of the team? And if so, how does that work?
I want to explore trust in this article. I’ve done it before, but an interview by Jeff Nielsen inspired me to revisit it.
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 read a recent article/blog post by Steve Johnson where he made the case for something he calls “market stories”. Here’s a snippet from the post:
Lately I’ve been talking to people about “market stories.” Combined with personas, market stories describe the market problem on an emotional level, before you break it down into product stories and user stories and tasks. They inspire our internal teams to want to help customers as people, not just as buyers.
For example: “My father wandered away from home and we can’t find him.”
I think it was George Dinwiddie that first coined the term “3 Amigos” in agile development around 2009. The analogy was akin to the movie from the mid 90’s by the same name. The Amigos in the agile sense are functional roles:
- Developer(s);
- Tester(s);
- and the Business Analyst or the Product Owner.
It could literally mean more than three as well. The point was, balanced collaboration in agile teams across these roles. George was alluding to these roles from an Acceptance Test Driven Development (ATDD) perspective. He wanted these three constituencies to be heavily collaborative (conversations) around the Acceptance Tests or Acceptance Criteria for each user story.
In my travels I spend a good deal of my time discussing Scrum Product Ownership, Product Backlogs, and inevitably User Stories. Stories are containers or artifacts, which have nearly become ubiquitous for handling software requirements within agile teams.
Most seem to be a using the standard phrasing construct for his or her stories:
As a – User
I want – Feature or Functionality
So that – Business why, What problem does it solve?
Because the “User” clause is so simple, I see many teams who fill out their user stories in a by-rote fashion. They’ll literally have hundreds and hundreds of user stories, features, themes, and epics and all of them have “User” as the user.
It happens to me on a weekly basis. I’m teaching a class on how to write User Stories. Usually it’s part of my Product Owner workshop. We’re happily writing stories for an iPad application simulation. Typically halfway thru the exercise someone raises their hand because they’re struggling with the format of a purely technical story. Quite often they don’t know how to frame the “user” clause and are stuck there in their writing.
My first recommendation is often to tell them to skip it. I tell them that the “As a” and the “So that” clauses are usually quite different for technically related stories. I just ask them to quantify the need (technically), in clear English with perhaps a couple of sentences, and then move on.
I hear this challenge over and over again from Product Owners. They have little to no problem writing functional User Stories, but then…
Bob, the team is placing tremendous pressure on me to write technology centric User Stories. For example, stories focused on refactoring, or architectural evolution, or even bug fixing. While I’d love to do it, every time I give them to the team and we discuss them, they nit-pick the contents and simply push back saying they can’t even estimate them in their current state.
So I’m stuck in a vicious cycle of rinse & repeat until the team gets frustrated and pulls an ill-defined story into a sprint. And this normally “blows up” the sprint. What can I do?
I think the primary root cause of this problem is that the company views the Product Owner role as the final arbiter of user stories; meaning they need to write them all. I feel that’s an anti-pattern myself, but the question remains, what to do in this situation.
I’ve seen several clients apply approaches that significantly helped in handling, what I refer to here, as technical user stories. Let me share a couple of real-world stories (nor user stories mind you ;-) that should help you envision some alternatives.
If you've been listening to our Meta-casts lately, Josh and I have been talking about the role of the Product Owner quite a bit.
We've been discussing questions like:
- Do you need one?
- If you do, what is the 'profile' of an excellent Product Owner?
- What do they do all day?
- Etc.
We've then been talking about a view I have about the role and the four key areas that you need to cover in order to do the role justice. I talked about them in my Scrum Product Owner book:
- the role is part Product Management
- part Project Management
- part Leadership
- and finally, part Business Analyst
I wish I would have come up with the "quadrants" notion when I was working on the 2'nd edition of the book...but, I didn't. But now I AM talking about the nuances of the role from a quadrants perspective.
