Have you ever found yourself working as part of a large program with a lot of activity but not much progress? It could be rewriting a 20 year old system, customizing a COTS application, or building a data warehouse.
You may have been told that adopting agile approaches will help you deliver those types of efforts better, faster, and cheaper. You may have also found out that it’s not quite that simple. If you make your delivery process more efficient, you may just be delivering the wrong solution to the wrong problem faster.
Joint Kent McDonald to find out a practical and effective approach to discern if you’re solving the right problem, and discover the right product to address that problem. You’ll learn how to structure your next project to:
- Identify the problem you’re trying to solve
- Make sure the problem is worth solving
- Iteratively discover the right product to solve that problem.
Along the way you’ll learn about and practice a collection of simple techniques that you can use right away.
- How to use a problem statement to help your team understand the problem you’re trying to solve and determine if it’s worth solving
- How to use decision filters and story maps to guide your efforts to discover the right product
- How to use backlog refinement techniques to build a shared understanding of your product
Problem Statement Exercise
Your group organizes an annual conference for business analysis professionals. The conference is usually a week long in-person event with ~1,500 attendees. For this year’s version of the conference conditions have made it so that it’s not safe to have an in person event.
Your group has been asked to plan an event that delivers the same value as past events have provided but is safe for people to attend.
As a starting point to your efforts, use the Problem Statement technique to build a shared understanding of the problem you are trying to solve.
Have each person in your group record their version of the problem statement in this Google Sheet.
Story Map Exercise
Let’s assume that your group has held some discovery sessions to get a better understanding of the problem you’re trying to solve and now would like to use Story Mapping technique to organize your backlog in order to identify the items that should be in your first release and the items you’d like to start with.
These Google Sheets have a collection of backlog items that you can use as a starting point to organize your backlog. Feel free to split up some of the big chunks if you need to. Record your selections in your Google Sheet.
Coming from the breakout rooms, be prepared to describe which items you feel are essential, which ones you would start with, and why you made the decisions you did.
Backlog Refinement Exercise
In your groups, discuss how you currently setup your backlog refinement, or how you may set things up based on what you’ve learned during the session and what is described in this description of how one team structured their backlog refinement.
Discovery Sessions: Start a project off right
A look at how discovery sessions help you to get you project off to a good start by making sure your product solves the right problem.
What is an agile business analyst
An excerpt from How To Be An Agile Business Analyst that explores the five characteristics of an agile business analyst, which also happen to be the five characteristics of effective product people.
The problem statement is a structured set of statements that describe the purpose of an effort in terms of what problem it’s trying to solve.
Internal Product Opportunity Assessment
The internal product opportunity assessment is based off questions in Inspired by Marty Cagan. They help product people determine if a product is worth it.
Outcome Based Metrics
Outcome based metrics are a way to quantitatively tell whether you’ve delivered an outcome and to avoid measuring progress and success based on output.
Decision filters are simple questions that help organizations distribute decision making by sharing strategy with those who have to act to make them happen.
Purpose Based Alignment
The Purpose Based Alignment Model, created by Niel Nickolaisen, is a method for aligning business decisions and process and feature designs around purpose.
The context diagram shows how your product interacts with outside people, organizations, and/or systems. The context diagram helps you to identify the interfaces you need to account for, helps you to identify scope, identify potential stakeholders, and build a better understanding of the context in which you are working.
A process model describes the flow of work or activities, usually in a graphic format, that contribute to accomplishing a specific goal. Process models are typically used to represent and analyze a series of activities that occur repeatedly and on a regular basis. Process models model the flow of work in or between people and departments in an organization, or the flow of activities in a computer system or application. The models have a clear beginning and end, intended outcome, order of activities, and different results based on the decisions that you make through the course of the process.
Risk Management Game
The risk management game is a collaborative way for your team to identify risks that they face, categorize those risks based on impact and probability, and determine which risks to address first.
A story map is a visual representation of a backlog that provides additional context regarding how backlog items are related to each other and when the team is planning to deliver them. This context is typically presented in terms of the personas that will use specific features, and the particular user stories that are associated with the features.
An example of backlog refinement for an internal product
Use process to get great outcomes. Here’s a description of how the team I’m working with right now does backlog refinement.
Discovery boards are ways for teams to visualize their backlog refinement process. The best discovery boards consist of a whiteboard or wall divided into columns that reflect the various steps a team takes to get product backlog items ready to be delivered (developed and tested) in an iteration. The backlog items are represented by sticky notes or cards that move across the board as the team builds a better understanding of the specifics of each story.
Definition of Ready
A definition of ready is an agreement on the set of conditions that need to be true in order to consider a backlog item ready to be included in an iteration for delivery.
Why you want to split your user stories
I explain why you want to split user stories and provide some references on how to do it. After all, Epics are for customers, user stories are for the team.
How to describe user stories to build shared understanding
Some techniques you can use to describe user stories to help you build shared understanding of your product and the outcomes you seek.
How to build shared understanding with example mapping
This session introduces example mapping, a technique that helps you structure your conversations and build a shared understanding.