[ad_1]

User stories can be one of the most powerful communication tools when used correctly. It also fosters a sense of unity within the team.

Yet, it’s easy to get caught up in the theory and not create something meaningful.

The process can become cumbersome, painful, and frustrating. Engineers may struggle to find the user stories helpful, seeing them as mere artefacts for Product Managers, while PMs must repeat themselves to be understood.

I’ve experienced this firsthand!

At the beginning of my career, I followed the principles that everyone recommended. I used the same template as everyone else: ”As a user, I want to be able to.” The Problem was that the teams I worked with disliked it for multiple reasons.

Moreover, I wanted to achieve my personal goals and create a positive development experience for my team. Even if the community recognises the ”As a user” template, most developers I knew didn’t find it meaningful. They were more interested in the accompanying Acceptance Criteria. We often spent more time explaining that sentence than working on the task.

Firstly, I wanted my team to feel part of the solution. I noticed that the Product team had spoon-fed engineers in many companies. It will only be done if something is in the user story or Acceptance Criteria. The famous “I only work on stories.” The behaviour comes from the culture of productivity pushed by management. This culture hinders agile development more than the framework and principles themselves.

Secondly, I wanted more time to focus on other tasks. It’s a Herculean task to find time for everything. I needed to change the way we worked and empower the engineering team. Over the past ten years, I have mainly worked in smaller structures, which meant I was responsible for all phases of product development.

I have always enjoyed games and finding the best solutions to problems. I also like to hack my way through life. This challenge was something I could tackle.

Over the years, I have developed my approach to creating user stories.

I love experimenting with the teams I work with.

I’ve worked with various teams, each with their unique characteristics. My leadership style focuses on allowing team members to develop their skills as they see fit. Everyone is accountable for the team’s work and has the opportunity to improve it. Our higher purpose remains the same: to deliver the best product possible as a team.

We win together, and we lose together.

I’m constantly measuring, gauging engagement, asking for feedback, and improving our work.

As a team, we aim to identify areas of frustration in our development process and eliminate them.

My personal goal is to enhance my team’s productivity. I don’t do this by increasing the workload or being a dictator. I do it by fostering happiness and ensuring everyone feels fulfilled.

Trying to do otherwise can be exhausting and feel like a constant battle with our team — a never-ending back and forth.

That’s why I’ve developed a more practical approach to user stories. The system encourages collaboration and shared understanding among team members.

The best way I’ve found to be most efficient is to build systems. These are processes and tools I can rely on and refine as needed.

Systems are also what I am passionate about. They are part of the experience we build for ourselves and the people around us.

I developed a system based on the principles of game design. Games have this never-ending phase where players can continuously find new ways to use skills, acquire new equipment, or enhance collaboration.

We sometimes forget that we learned as kids through games. Observing nature, we can see cubs learning how to hunt and survive by doing the same. However, there comes a point in life where we must leave games behind. Yet, a game is an opportunity.

”A game is an opportunity to focus our energy, with relentless optimism, at something we’re good at (or getting better at) and enjoy. In other words, gameplay is the direct emotional opposite of depression.”
―
Jane McGonigal — Reality is Broken: Why Games Make Us Better and How They Can Change the World

Four aspects constitute my approach:

  • Autonomy — People need to feel they can control the outcome.
  • Mastery — People need to feel they can improve in their areas
  • Purpose — People need to feel the meaning and the fact they contribute to something bigger
  • Community — People need to feel a sense of belonging

These aspects compose the system that helps me create unique user stories.

Games are all about balance. If a game is not well-balanced, players may lose interest as they feel cheated. The expertise of a game designer lies not in the storyline or graphics but in striking the perfect balance between offering enough autonomy to the player and providing adequate guidance to foster a sense of accomplishment.

I apply these principles to the product I work on, my leadership style or the user stories I write.

Remember, everything is a product!

The system I’ve developed is a mini product I’m sharing today. To create this system, I had to establish the right mindset. I applied the same principles and tools I use to develop customer experiences.

The first question to answer is: what value do I want to provide through a user story? Who is the target customer for that story?

The customers of their product may be the target customers of the user stories.

This isn’t accurate.

Customers don’t see our stories; they only experience the results.

The actual customers of our stories are the engineers. They use this product to create and deliver value to our customers.

Getting it right means getting the correct value. It also means being more efficient and effective in our dev process. It means less time spent on miscommunication and fewer misunderstandings. Ultimately, it results in a happier team and a better product.

Following the mantra — People, Product, Profit!

So, how do we create user stories that resonate with engineers? How do we create user stories that foster a more efficient development process?

Finally, I want to make it my own. What is the unique value I can bring when crafting user stories?

First, user stories originate from a use case: no use case, no story. Regardless of the scenario, engineers need to understand the story’s context.

Here are some critical steps to consider:

1. Simple Title

Create a concise title that conveys what the user story is delivering. Starting with the outcome is a good approach. If you use Jira, the board view can feel cramped. Suddenly you only see the “As a user…” on the card, which makes it meaningless. Use a title such as “New Settings for Documents” or “Onboarding Process for New Customers.”

2. Include background and the “why.”

Provide context and the reason behind the user stories. Explain why we are working on it, the value it brings, and for whom we are creating the solution. Everything is contextual. Engineers can find the best solution to the problem we are trying to solve and the value we are trying to achieve if we give them the proper context.

Giving a task to engineers and withholding the essential part of the information will not help anyone. It is not because, as PMs, we transfer our knowledge that we lose power. It’s the other way around.

3. Use the following format

“When [Persona] is doing [Use case], the [Problem] occurs, which leads to [Emotions]. Instead, they should be able to [the new experience], which will help them achieve [value/goals/benefits].”

This format communicates the user’s experience, emotions, and desired outcome. It enables our team to develop solutions that address users’ needs. It also improves engineers’ experience.

4. Add visuals/workflows

“An image is worth a thousand words”. Incorporate visuals and workflows that help engineers understand the desired outcomes. This can include diagrams, mockups, or flowcharts. A diagram can convey more information and help find the missing pieces in the experience. We all have different ways of working, learning, and understanding information. We must adapt to each style to get the most out of everyone.

5. Ensure stories are SMART

SMART is a checklist that I use when writing my stories. If I can’t figure out one of the letters of the acronyms, it helps me work on my user stories to be more precise. SMART stands for:

  • S for Specific. The story must be clear and state a user’s need.
  • M for Measurable. The team must be able to measure if we have met the story’s objective.
  • A for Achievable. Is the story realistic or attainable? It could be impossible to do it now with the current tech stack.
  • R for Relevant. Does it matter if we achieve it? Is it worth our time?
  • T for Time-bound. The story needs to be delivered by a deadline. It will be mainly judged based on the length of the sprints. Whether it’s an epic or a story, there should be steps we can take to accomplish it.

6. Explain the constraints

Clarify any limitations or dependencies the team should know when developing the feature. Do we have performance expectations? Does it need to run at a specific time or night? What do engineers need to know that can affect or meet users’ expectations?

7. Identify rollout

Incorporate how we plan to launch and deploy the feature. It will be developed a certain way, if it’s a small rollout or an experiment. How you will deploy will help the team understand the required expectations.

8. Work from the end of the process

Once completed and when we start grooming the story, I agree with my team on the use case scenarios for testing the stories. Use case scenarios allow engineers to define how they will test the stories. In doing so, we can identify gaps or misunderstandings.

9. Give engineers autonomy

PMs don’t need to come up with all the solutions. I know we love it, as it gives a sense of power and meaning. Yet, engineers’ solutions are generally better than ours. It doesn’t mean we can’t challenge or help them groom the story. Our participation matters. However, it’s best to encourage collaboration and allow engineers to contribute their ideas and expertise.

10. Iterate and improve

The most important part of the process is the never-ending journey to greatness. We must continuously gather feedback and refine our approach to user stories as a team.

[ad_2]

Source link