Struggling project? Maybe it’s your user stories!
Are you on a sinking ship? If your agile project is struggling to stay above water, it’s possible you have holes in your user stories! Do a quick user story inspection. Do you see any of these warning signs?
1. Inside Out User Stories: Do your user stories focus inside out (technology, then user) or outside in (user then technology)? When I coach agile teams, I often see user stories organized by technology component instead of user value. A piece of technology, all by itself, does not typically provide value to the user, especially in our complex integrated environments.
If applications (a.k.a. stand-alone systems or components of systems) are integrated, then user stories should be integrated. Why? It’s all about user value! When a user makes an online purchase, they do not see separate applications. They browse items, make a purchase, pay, and receive items. Users do not get value from the web page alone, the product database alone, or the payment processor alone — the user gets value from the integrated experience. Value from a user perspective comes from integrated user stories vs. single applications.
2. User Stories Focus on Project Team Tasks: Again, this approach is not user-focused, it’s development team-focused. When user stories or story sets describe a list of team tasks, they lose their power. If your user stories have names like “code profile page” or “write SQL for DB call” or “map data for credit card validation,” your project might be in trouble.
Teams need to operate from an outside-in perspective–focusing on the user and what they need. Team tasks are different than user stories. They may be linked to one another to keep organized, but these team tasks are NOT the user stories.
3. Huge User Stories: If your user stories cannot be developed in the planned iteration, they are too big. SLICE THEM! But be careful how you slice them. Take note of warning signs #1 and #2–slice user stories by value, not by team tasks or applications. The entire user experience and all exceptions do not need to be in the same story. For example, A story about creating a user profile can be sliced into multiple stories. Slice them based on the valuable pieces of data that make up the profile, instead of the application components the profile touches.
Why Agile Teams Need More Than User Stories To Build Great Products
A Tale of Two Teams
Let’s take a look at backlog refinement from two approaches:
A customer provides the team with feedback on their website ordering process and says “I want a button on my email receipt for my order to “view shipping details”. The team prioritizes this and gets to work. They build it quickly in a sprint and release it. Then, weeks later they get feedback to add shipping details to the “My Orders” page. The team thinks okay, let’s get it done, and does it in a sprint and releases. Along with six other seemingly small requests related to shipping information in the next three months. The team has taken requests from the backlog, prioritized them, implemented them, and is doing great agile work right? But, there really isn’t much analysis happening here.
Looks at their backlog more holistically and analyze the user problems, observe users, talks to users and analyze the bigger picture of what the users are trying to accomplish. They do this continuously and iteratively, not all in a phase. They deeply understand the users and user problems and discover the user is frustrated by packages arriving when they are not able to be there, and the user wants to update the shipping information after they see the expected arrival date. It could be things like, reroute the package, or add special instructions to leave at the back door. In response, they ideate, analyze the current user workflows and determine a solution to solve the problem; they also find the 18 requests related to this process in the backlog. They analyze and refine the backlog to split out the solution into a few experiments and iterations to learn if their solution is working to solve the problem or not. They learn as they incrementally deliver parts of the solution to users, and continue to refine the backlog as they learn. They are analyzing a holistic backlog with a user problem in mind to solve. They are doing analysis!
Agile doesn’t mean skipping the analysis!
- Team A, never really solved the problem, made the user experience more frustrating without realizing it, and had 15 more requests related to the same problem in the next two months.
- Team B, the competition, solved the problem by focusing on the user problem and analysis of it, rather than working on a list of requests.
When we skip the analysis (Team A) we are essentially repeating the same pattern that brought us to use agile from the start. Right, agile is supposed to help us build higher quality software that is more relevant to users and faster? Typically, many teams and organizations were frustrated with slow progress on projects. Requirements and Analysis took too long and progress was only seen when the software was built. Therefore, it made sense that agile would “solve the problems”. Historically, the challenges were: a) requirements and analysis took too long, and b) when the product was delivered it wasn’t the right product users needed. Consequently, something has been very flawed with requirements and analysis processes for a long time in many organizations. In transitioning to agile ways of working, let’s not get rid of analysis, however, let’s fix it so that it does not slow teams down, it’s not a phase to be waiting on, and it’s not a one and done process. Ideally, the analysis should be lightweight, continuous, and user-centered in order to work and leverage the benefits of agile.
When teams build great products they develop some common patterns.
- They deeply understand their users’ goals, pain points, and opportunities.
- They are open to looking at different solutions in order to solve the users’ goals.
- They understand the users’ goals and behaviors within a larger context than the product itself.
User Story Efficacy
User Stories are intended to be a placeholder for a conversation, and these are conversations about users, their goals, and the bigger context in which users need and use our products. User Stories are not a list of technical action items that the team trudges through to claim they are “getting work done” and being efficient. Teams that are only using user stories as a “to-do” list are missing most of the true benefits of what they are all about and are likely to miss identifying the other analysis that needs to happen in order to build successful products users/customers love.
User Stories are a placeholder for a future conversation. This leaves substantial analysis incomplete. The acceptance criteria for a user story is a large part of the analysis, but there is more. I am not advocating for big upfront analysis phases and processes, rather more of an iterative, lightweight, and ongoing analysis so that teams can continuously learn about the users and their needs in order to effectively prioritize the backlog and innovate. Even for products and teams working through enhancement and defects lists, understanding the users and their requests deeply and continuously are critical to team efficiency and effectiveness.
What does good analysis look like for new and existing products?
- A holistic backlog that is analyzed and prioritized against a user’s problems/goals, not a list of requests that have come into the team.
- Using lightweight visual models as team assets (hung on the wall or virtual wall) to continuously discuss user scenarios. (like Miro or Mural) Models like: user story maps, user-focused process flows, sequence and state diagrams, user-centered process models, customer journey maps, decision/logic tables, data flow diagrams, etc…
- Frequently observing customers and users in order to understand what triggers them to use your product, understand their emotions and pains before, during, and after a product interaction.
- Bringing the team deep conversations about the users, scenarios, user context, and user pain.
- Prioritizing the teams work based on desired user behaviors and goals within a product
- Analyzing the backlog holistically and aligning it to higher goals, rather than item-for-item as individual requests.
- Finding small experiments to try out that tell the team if they are on the right track to solve the user problem.
In conclusion, without analysis, it’s easy for teams to build uninspiring products that end up with lots of defects, enhancements, and users that just don’t like the product. Why just build it fast, when you can build the right thing fast with the agile analysis done well?
Let’s get back to doing analysis well; continuous, fast, and building great products!
User Stories: Your First Step Should Always Be Back
Have you ever played an outfield position in baseball or softball? As an outfielder, your primary responsibility is catching pop flies.
When you hear the crack of the bat, there’s a moment of panic as you try to figure out where the ball is headed. For young players, their first instinct is always to run forward, which usually leads to the ball flying over their head and the batter advancing several bases.
When I played softball, my coach had a mantra for outfielders, “Your first step should always be back!” The coach asked the outfielders to take a quick step back, gauge the ball’s trajectory, and then choose their approach.
Our backlogs are filled with hundreds of pop flies. And to build better user stories, our first step should always be back. We need to step back, check our sources, and analyze the big picture before we decide how to proceed.
Where Do All These Pop Flies Come From?
When the backlog items come flying at you, it’s important to take a step back and figure out where they are coming from. Are your stakeholders like methodical ace pitchers or are they wild and erratic? Does the product owner swing at anything or do they evaluate each pitch to see if it’s worth a swing?
Most backlogs are filled with a random mix of enhancement requests, defects, and ideas submitted by a random mix of stakeholders. If BAs work the backlog as is, without discovery and analysis, the team will struggle. Delivery will be slow, teams will build the wrong things and customers will be frustrated. BAs will be bogged down by a never-ending backlog of more requests and missed requirements.
Existing backlogs need to be aligned to strategic priorities. BAs need to step back and look at how backlog items connect and how they align with organizational goals. Ideally, BAs analyze and transform these submitted backlog ideas into better user stories that give stakeholders and end-users what they really need versus what they think they need.
Work With Your Pitcher And Batter
After you step back and really examine the backlog of pop flies, it’s time to tame your wild pitchers and help your batter develop a more selective swing. The discovery process engages project leaders and stakeholders to develop a shared understanding of needs and priorities. It’s all about getting the team thinking and talking.
Ideally, and good practices are for BAs to use multiple techniques to help teams discover what’s possible and solve problems. The most effective discovery sessions help teams generate ideas, evolve, and innovate. They include collaborative elicitation experiences that inspire meaningful dialog between stakeholders.
Just sitting around a table and talking isn’t enough—build engaging activities, prepare thought-provoking questions, get people moving by building visual models with sticky notes or drawing on whiteboards, try gamestorming, etc.
As the team moves through the discovery process, it’s important for BAs to make time for Moneyball.
Do you remember Moneyball? Adapted from a book of the same name, the popular 2011 movie tells the story of a famous baseball guru who stepped back, analyzed the game, and changed the way organizations build winning baseball teams.
This is the job of every BA. “Go Moneyball” on the backlog and user stories! Analyze the results of the discovery sessions to reveal gaps, make connections, and define the real problems.
BAs can’t skip analysis. This BA thinking time, outside of the discovery sessions, is where BAs really boost the value they provide. When BAs analyze processes, data, and people, they find impacts and gaps in known requirements and ultimately deliver better solutions. This is the time to pull out your analysis models and techniques to help you think and analyze.
Getting The WIN!
When BAs take a step back, create engaging discovery activities, and make time for analysis, teams are much more likely to get the win. But remember you don’t just move through these steps once. You don’t just look at the backlog, do one discovery session, then analyze and go— it’s an iterative process.
BAs repeat the elicitation cycle over and over as they dig deeper into details. You’re really playing ball when you find ways to experiment with and test what you’ve learned from discovery and analysis.
Good user stories and good requirements in general, always come back to the basics of business analysis and making sure we advocate for the elicitation and analysis pieces of our BA approach. Don’t just chase after every pop fly that comes your way. Make sure your first step is back so you can get the perspective you need to help your organization win.