„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“.
Understand the user story
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
- the need to create a report for a manager,
- the preparation of a meeting with another team’s developer,
- a reminder to fix a bug or
- the set up of a new test environment.
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.
Following the reward
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:
- I had my annual performance review. I talked with Boris about how I had developed during the last year, how well I had served his vision of easing the life of employees, so that they still have some energy left after work to play with their kids at home. And of course, I listed my goals for next year. Starting next month, I will get a higher salary which feels good to me. Basically, I got rewarded by my boss.
- My colleagues help me in daily business. Without them my work life would be a lot harder. For instance, before I release a blog post, two colleagues are asked to read and review it in advance. We support each other. Thank you, guys, I publish better blogs because of you and this feels good to me. I am rewarded by my colleagues.
- Every Monday, on my way to my client, I got about 15 minutes in the station: five minutes for getting some croissants from my favourite bakery, five minutes to get a ticket and finally five minutes to get a seat on the train. Since I got the free ticket app I have got ten minutes more – I can sleep longer, I can extend showering or do something else. I have served myself well. That again feels good to me. I just rewarded myself.
For good and biological reasons, we tend to focus on something we get rewards from.
User stories keep the focus
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
Marcus
