You need to enable JavaScript in order to use the AI chatbot tool powered by ChatBot

What structure do you consider best for a user story?

What structure do you consider best for a user story?

Welcome to part 25 of our scrum master interview questions series where John McFadyen answers common questions asked of scrum masters in interviews and client engagements.

Something that you see in so many scrum environments is the:

  • As a … (insert context of the person who needs the item)
  • I want … (describe what the person is trying to do or the problem they need to solve)
  • So that … (describe the outcome that the person will achieve because of the item)

That is often the construct we see for a user story.

It’s a good construct, created roughly 20 years ago, and it serves to help frame the problem that needs solving or the context of the solution that needs to be created.

At the birth of agile, the user story helped the team understand:

  • Who wants the item?
  • Why do they want it?
  • How will it serve them to have it?

So, whilst that structure has helped teams evolve and build products that delight customers, it isn’t THE structure, nor do you have to use that structure to be effective.

The purpose of a user story.

At the birth of Extreme Programming, the user story was created to help developers understand the context and purpose of the work they were doing. Often, the problem had never been solved before nor had the product ever been built before, and so they needed to ensure that they were focused on creating the most valuable solution or solving the most compelling problem.

There are a myriad of different ways in which you can build something, and you can optimize it for any number of different applications, and so it is helpful to understand the specific problem and application for the product, and why it matters such a great deal to a customer or stakeholder.

That empowers the team to focus on building the highest value solution in the shortest amount of time, whilst investing the least amount of effort to achieve the outcome.

Effectiveness rather than Efficiency.

The founding fathers of agile understood that we tell stories every single day, and the best way for us to learn and understand things effectively, is through story.

It made sense to write a brief story about the person who needed the item, the challenges they were attempting to overcome, and how this new solution would empower them to achieve their goals and objectives.

Context. Purpose. A deep understanding of what needs doing and why it is important.

Harnessing the power of stories.

When we were kids, we learnt about the world and how we were supposed to behave through the stories and fairytales that we learned. As adults, we form connections or reconnect with one another through the stories that we share.

Story is incredibly powerful for framing problems and empowering others to understand the challenges we face, on a visceral level, in a way that inspires them to help or contribute.

So, given that purpose, what would be a useful format for a user story?

Truth is, it could be anything that achieves that goal. It doesn’t have to follow a specific format nor is there a one-size-fits-all practice for a compelling user story, you can use whatever format you like as long as it is authentic, concise, and promotes understanding and insight for others.

We want to capture the stories about the problems that our customers are trying to overcome, the utility and/or necessity of the product that is needed, and how that product or feature will deliver a tangible, measurable benefit to that customer.

Don’t get too caught up in a specific structure, focus instead on capturing and conveying the information that everybody needs to create something of value for the subject of the story.

A user story is a placeholder for a conversation.

Something that people often forget when thinking about user stories is that they are important prompts for valuable conversations. They are not a replacement for those conversations.

You aren’t trying to capture absolutely everything imaginable in the user story, it isn’t an essay that allows you to hand it over to someone else and crack on with what your job after that. Instead, you need to think of a user story as something that will allow you to speak confidently about the problem, articulate the purpose of the item, and help developers frame the problem in the most valuable context.

Don’t neglect the conversations, they are essential in helping developers understand what needs to be done, and how best to go about building the solution or solving the problem.

So, we want something that is imprecise. We want something that is a starting point for a conversation rather than an explicit instruction on how to do the job.

The developers are the experts who are best placed to decide how best to solve the problem or build the product, so we don’t need to tell them that, we just need to frame the problem correctly and provide the context that allows them to come up with a creative solution.

So, in closing, I would recommend that you work on capturing the essential information needed to facilitate a conversation with the problem solvers rather than attempt to write the perfect user story.

If you’re still writing after 3 minutes, I would advise you to scrap that and start from scratch again. You are overthinking the user story and more than likely attempting to capture too much information.

Just focus on a concise, simple story that facilitates a valuable conversation with others.

About John McFadyen

If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.

For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.

If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.

If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.

If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.

#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster

author avatar
John McFadyen Managing Partner
John McFadyen is an Executive and Enterprise Agile Coach with proven experience working on some of the UK and Europe’s largest, most complex Agile Transformations. As a Certified Scrum Trainer, John brings a wealth of experience as an Agile coach, Agile practitioner and software developer into each of the four core courses he provides. The war stories, the insights into successful Agile transformations and everything he has learned from coaching high-performance Agile teams combine to provide course delegates with a unique, compelling training experience that transforms as much as it empowers.

Like this post? Share with friends & colleagues using the share buttons below.

Facebook
Twitter
LinkedIn

Related Blog Posts

Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen
Deploy + Improve Scrum
John McFadyen