While there is no shortage of different ways to upset someone working hard and under stress, I'd like to share a real life story to illustrate how even seemingly innocent discussion can have unintended effect.
As a product owner I began noticing more and more technical stories added to my backlog by the scrum team members. These stories often focus on improvements that are not immediately clear to the end user of the product. In many cases with a little extra effort it is possible to rephrase the description to turn them into user stories. In other cases, these are indeed technical stories benefiting developers more than the end users.
Here is how I tried to explain to my scrum team why I am not the right person to rank these stories for them.
I told them as a representative of our customers, I want to understand the value of every story on the backlog in as far as it relates to a tangible product feature or a capability. If I see enough value to potentially pay at least $1 for the feature, this means a story is a valid user story and I should be able to rank it. For example, if I buy a car, I may care about maximum speed, rear view mirror and even the type of stitches used for my seat covers. As long as I care for these things, I could potentially arrange them in a ranked list. On the other hand, features that I don't understand... I simply don't care about. For example, I don't care if my car is powered by a V-type, in-line, horizontally-opposed or rotary style engine, what type of alloy is used in my brake pads, or that my SUV came from the same assembly line that also makes minivans.
I told my team they are welcome to use technical debt for these stories, which can take as much as half of our typical sprint velocity. The team knows better which of these stories are more important and should make prioritization decisions based on technical merits, not the product owner.
Can you see a problem with my reasoning? If so how would you go differently about it?
Hey Oleg,
ReplyDeleteI do appreciate this particular post very much. I have followed a different approach than yours, but I wonder if yours might not be actually better.
I have basically let the team know that they should feel free to add stories to the backlog, however I have asked one thing of them. That these be written in the canonical form so we can clearly see what and who the benefit of that story is. This way I get to "understand" the value of the story and I was able to rank it along the other stories. I usually think it's better to have a say in what's happening, since if you don't that means technical stories with extremely low benefits might get worked on before those stories that you really want to make it into your release cycle.
But as I said, I think your way of dealing with tech stories might be better if you can allocate a fixed percentage of your bandwidth to work on technical debt, since that would allow you at planning phase to know how much bandwidth you get for your "customer" stories, and saves you the complexity of dealing with technical stories.
That being said, I have encounterd great benefits in having the team try to frame the stories in canonical form, since it also helps the writer think about the real "customer value" of the story, and sometimes saves some arguments, since they might realize by themselves that what they're proposing is indeed very cool, but quite expensive compared to low added customer value.