„We are using user stories instead of requirements.“ Probably everybody working in a Scrum environment already heard this sentence – to some it sounds smart, to others it simply sounds dangerous. Wow, no requirements! It is one of my favourite false statements concerning Scrum, right after: „We do agile, we do not plan anymore“ and „Self-organization does not need leadership“.
User stories are part of the family of functional requirements, containing many kinds of requirements. But I do not mind the wording aspect, because we need to change and differenciate words to embrace a new culture. I prefer to take a look at the context behind such sentences which is: In Scrum we try to express user-centric requirements in a story-like syntax.
But in many cases user stories are actually used to describe
And Scrum Masters keep asking: „Who’s the user?”
And developers respond: „Well, my manager is the user!” or „My colleague might be the user” or „I see it clearly now: I am the user!”
And every Scrum Master needs to say: „Well, that is correct”, because in literally 90% of these situations that is the case.
And that is how we miss the unique magic of a user story.
Most of us were trained to serve the company, serve the boss and serve ourselves. Far too often, this is what we are rewarded for. Here are some examples I experienced myself within the course of only one week:
For good and biological reasons, we tend to focus on something we get rewards from.
Back to the business context: In a complex product development process, we can easily lose sight of who is finally rewarding us for our good work. Sometimes we even just don’t know who actually pays our salary. In any case it is the user who buys our cars, our 3D printers or uses our new fancy banking app. The main problem is that developers often don’t focus on the actual user. At this point, the magic of an user story helps a lot: It focuses on the user. Not on the manager, not on the colleague and not on ourselves. The user story is supposed to be decoupled from reward systems usually in place. It solely focuses on the user.
By attaching value to the outcome for the user, a user story shows every day how much benefit a team is delivering to the guy it is paid by. And this is the reason why we use this kind of requirement in Scrum. Scrum is user-centric, it is about getting feedback about what a user might need or love and why!
With this in mind, yours