What do you do if the team aren’t creating or using user stories in their backlog items?
Welcome to part 41 of our scrum master interview questions series where John McFadyen answers common questions asked of scrum masters in interviews and client engagements?
This is a shocking interview question. Who cares if the team aren’t creating user stories and logging it in the backlog? Why does it matter?
- Are they capturing the customer needs?
- Are they capturing the organizational need?
- Are they capturing what needs doing and why that is important?
- Are they capturing information in a way that they, as the developers, understand?
If so, it honestly doesn’t matter if there are user stories in the environment or not.
If the developers have a clear understanding of the problem they are trying to solve, and they know why it matters to the customer, and how it will enable the customer, you are winning.
The purpose of a user story.
The purpose of a user story is to spark a conversation about what is needed, who needs it, why they need it, and how it will empower them to do something or solve a specific problem.
It isn’t meant to be the map of the entire territory; it is meant to be a marker that inspires a conversation between the developer and the customer or product stakeholder. It is meant to provide just enough information for developers to grasp the problem or define the opportunity.
It isn’t a MUST in scrum or even Agile for that matter. It was simply invented as a way to get the ball rolling in the right direction, but it was always going to be replaced by a process of practice that worked even better for developers and customers/stakeholders.
So, don’t get caught up in crafting the perfect user story and insisting that everyone does this, allow people to discover and implement a better way of capturing what they need.
Don’t get caught up in the dogma of Agile.
There are purists who insist that everything must be done a certain way, preferably their way.
That just isn’t necessary. We are aiming for agility rather than worshipping down the hallowed halls of agile. Nowhere in the agile manifesto does it say that you should abandon great work in favour of a recommendation or suggestion.
What you need to do, instead, is look to find ways that really resonate with your team and allow them to do great work. For some, that’s a use case document that captures a great deal of detail and articulates the need incredibly well. For others, it’s simply a post-it note that encourages them to have a conversation with the product owner, customer, or product stakeholder.
Both are great examples of how to prepare for backlog refinement and engage customers and stakeholders on what is needed and why that matters. This goes for all elements of scrum. There isn’t a perfect way to host a sprint review or sprint retrospective, but there is a great way that works for your team and in your unique application.
Empirical Process Control.
Scrum is built on the foundation of empirical process control. The three pillars are transparency, inspection, and adaptation.
We don’t know the answer upfront because we have never solved the problem before. We don’t know the solution because we have never built the product before.
We have to form a hypothesis, create an experiment, run the experiment, inspect what has happened, and then use the data and evidence to inform what we do next.
This is empiricism.
The developers or product owner will capture the essential information they need to understand the problem or opportunity, and decide whether that is enough to begin work on the item or whether they need an additional conversation with the relevant person before committing.
Sometimes, the user story doesn’t come from the product owner, the customer, or the product stakeholder. Often, the person who best understands the problem or understands the need is the perfect person to capture the information and host a discussion about that item.
Allow people to do that in the way that best works for them.
Encourage them to use a format that empowers them to speak about the problem, outline the opportunity, and describe the best-case scenario. What that looks like, sounds like, and feels like doesn’t have to be governed by a user story.
It just needs to be enough for the team to have a quick chat about it, pull it into the sprint backlog, and begin work on the item. As they work through the problem, they will learn and either build the item or bring it back onto the backlog because they have encountered significant obstacles.
It may have dependencies that weren’t clear at the start. There may be systemic or organizational issues that need to be resolved before the item can be completed. There may be hundreds of reasons as to why it can or can’t be completed.
The process of creating the product will inform what needs to happen, you don’t need to capture absolutely every element of the problem in order for it to go into production.
So, in closing, don’t get caught up in user stories and don’t force anyone to use them. Find what works for you, for the team, and your customers and stakeholders.
About John McFadyen
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