Do Your Scrum Teams Enjoy Developing Your User Stories?
Remember the number of surveys, the questionnaires or the number of user interviews that you conducted for your product? All these are the mediums to understand whether you are actually building the product that users will love to use and more importantly, you are actually trying to solve a real problem that is worth solving.
Being a product owner, you also have some products which are your own, and you are solely responsible for their success. No, I’m not talking about that fabulous mobile app that you are currently working on or not even the product demonstration that is lined up next week. Considering all those different types of surveys and interviews are pretty obvious for these things. But have you thought about how's the experience of your user stories? Are your Scrum teams really enthusiastic when they get to develop one of your user stories?
Because we — the product owners — create numerous stories throughout our lives, we tend to forget that it is also a kind of a product that we are delivering. And thus, it is important to realize where our product stands and how the users feel about it.
Here are the factors to consider when checking on the experience of your user stories.
- Learnability of the stories
Is your user story learnable? Would any random Scrum developer be able to understand your story, given a brief context?
It is quite normal that the developers working on your stories might get replaced through the same or different sprints.
The learnability factor starts right from the fact that whether your story user (Scrum developer) understands the purpose of the story, the persona of this story, the platform to support and the boundaries of the scope of this story, clearly.
How to achieve this:
Mention the purpose of the story briefly. Let the developer understand why he/she is asked to implement this particular story.
Clearly define the persona of the story. Needless to say that the story content is expected from this persona’s perspective. If required, you can attach a visual presentation of your persona giving more background about him/her. It can include details like the name, age, location, professional and personal background, routine activities, pain points that he faces — that your story is going to solve.
Mentioning the platform in each story will keep the Scrum team reminded of the specific platform that you plan to support e.g. A mobile app on a specific Android/iOS version, specific browser and so on.
The scope defines what exactly this user story is focusing on. The scope can be, for instance, limited to converting existing application to new look and feel, or involves developing a new API along with the UI and so on.
Attach additional resources to your story, which would help the developer gain deeper knowledge from technical perspective. This can include the solutioning document, any UX and UI design created for this story.
2. Enjoyment factor involved in the stories
There are multiple templates to write your user stories and its not the one template that fits all. You might need to change the templates / patterns based on the type of the story. For example Given-When-Then pattern is useful for the stories involving UI development but not necessarily for the stories involving accessibility requirements.
How to achieve this:
Try different patterns for different types of stories and see which pattern is enjoyed by your Scrum teams.
One more way of making stories interesting is to add pictorial representations. As they say, a picture can say thousand words effectively. This can be short screenshots from your wireframes that represent the specific acceptance criterion, or hierarchy diagrams making the concept clear or any other diagram that you find meaningful. The idea is to make the stories enjoyable and not tedious.
At the same time, pay attention to the story size as well — not just from the efforts perspective but also from the actual length perspective. Too many details can take the enjoyment factor away, too.
3. Usability of the stories
Can a developer use your story to its full potential? Does he/she still miss some of the acceptance criteria? These are some of the questions to consider while thinking about the usability of your stories. It is not at all meant to cut off all the conversations between the product owner and the developer — that is a lifeline of any product. The idea is that the interpretation out of your story is precise and exactly what you meant.
How to achieve this:
Be very clear about your acceptance criteria. Avoid huge statements and uncommon wordings. Keep it simpler, precise and to the context. Provide the ‘terminology’ definition if required. This is especially when the teams are not familiar with the newly introduced terms.
Also, define any configurations that you would like to implement. This is essential to make your product flexible. Usually, such details are mentioned in the solutioning documents. But mentioning them in the user stories has its own advantage. They help the teams understand which configurations are relevant to particular requirements and ultimately ease their job. And it is also beneficial for you while having the story demonstration.
4. Does it generate some new idea / scenario?
This is a bonus point. Is your team aware about the market competition? User story, is the way to do that. You can introduce some market competition / situations through your user stories. This will help your team understand where we stand today and what we want to achieve or at least the mistakes that we want avoid.
How to achieve this:
Provide some screenshots of similar applications, available in the market. And ensure that your teams are aligned on the fact that these are just the references. Ultimately, we don't want to create copies of existing applications.
Such references can also trigger some new ideas to your teams which you would be happier to discuss and probably add into your product backlog.
The whole idea here is to make your user stories more impactful and to be used to their full potential. This does not, in any way, mean to cut off the useful conversations between your teams and you, neither it means to spoon feed your teams.
