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.
