A Tale of Two Teams
Let’s take a look at backlog refinement from two approaches:
Team A
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.
Team B
Looks at their backlog more holistically and analyzes the user problems, observes users, talks to users, and analyzes 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!