When solving complex problems at scale, we use epics, features, and stories to align, focus, and coordinate the work of multiple teams to achieve the objectives of our organizations.
An epic represents the investment decision to solve a tangible problem; a collection of epics together represent a broader investment decision to advance the organization’s strategy. Most of the teams I’ve worked with in the past few years initially think about their epics in the wrong way – and once we change together how they write problem statements, it unlocks their potential to achieve great things on their own.
The Job of An Epic
A well-constructed epic achieves two objectives
- An epic aligns your teams on intent – why are we making this investment and how will we know we are done?
- An epic communicates the context of general approach – at a high level, what will we create and improve to make achieving our goals possible?
A group of epics collectively represents the purpose of a body of work the teams will perform in a period of time. Our executives validate the body of work as matching the ambition of their initiative. Together with them, we create the epic roadmap to align and allocate the organization’s capacity to the pursuit of our strategy. This coherence check is the first important alignment activity required to assure the organization is effectively executing on the vision of the organization.
For you to agree with my assertion about the job of the epic, you need to know the jobs of the feature and the story – to assure yourself this approach collectively gets all of the jobs of the system done.
A well constructed feature describes our approach to creating or improving a capability which we believe is necessary to realize the intended outcomes of an epic. Any given epic will be achieved through the development of multiple features. Each feature provides sufficient specificity to enable the organization to understand and orchestrate dependencies across the teams doing the work – and likewise provides enough information for the team to know how “good enough” will be judged – a definition of done.
An effective user story describes the user’s goal, when & why they have the goal, and how they judge their success at achieving their goal. A collection of user stories aligned to a given feature reflect the necessary adaptation of those user goals, given the constraints of what we build to enable them to realize their goals; given the features we might choose to build and the way we would choose to build them.
The Job of the Problem Statement
In any organization, an artifact exists to support activities – creation, collaboration, coordination, and communication. [Hat tip to Laura and Kate for the inspiration (in a discussion on the purposes of designers’ deliverables)] An epic is no different – and we use it for each of the 4 C’s, at different times, with different people, for different purposes. In support of those activities, we rely on the epic as a container of “intention.”
A good epic organizes the description of intent such that it enables teams to support conversations around three key questions:
- What is the problem we are solving for the company with this epic?
- What is the value of this epic, assuming we solve the problem we intend to solve?
- What changes in behavior will we observe in the short term which assure us we are solving the problem we intend to solve?
The problem statement has responsibility for the first of those three – aligning with our executive sponsor on the problem to be solved.
The problem statement is primarily a creation tool – for a product manager, properly framing the problem which truly needs to be solved is the vanguard of thinking steps in providing clarity in the backlog. Understanding what truly needs to be accomplished is an experience of epiphany and insight; a moment of clarity.
The problem statement is secondarily a communication tool – an elevator pitch for the epic. Our leaders rely on us to deeply understand the context in which we make choices which make plans real. Through the problem statement we can collaborate to achieve a shared understanding of how the teams will realize the vision.
A well written problem statement provides clarity on why an epic is valuable to the organization. Primarily, we use this to assure completeness and correctness between a collection of epics and the initiative. When we are misaligned, we leverage the problem statement in collaboration with our executive to achieve both alignment with and comprehensive coverage of the opportunities we are pursuing. This alignment is a key element of strategy deployment – making sure nothing is missed, and none of the work is likely to be misaligned.
An Effective Structure for the Problem Statement
On more than one occasion I’ve heard an effective product or business leader refer to structured artifacts as “mad libs” (and not in a good way). A mad lib, while fun to read, is not actually coherent or useful – arbitrary terms inserted into fields creates nonsense. Forcing people to restructure nonsense thinking into a good format initially results in well-organized nonsense. All is not lost, however, as this is also the first step on a journey of improvement.
We gradually adapt to the structures around us. Forcing teams to use a fixed structure for writing problem statements is an effective way to make progress addressing the system-level problem of developing the organizational capability of collaborative problem solving.
In the Shu Ha Ri approach to change, adoption of the structure is achieving shu-level performance. When our problem statement includes the right elements, it improves. Upon that improvement we can begin the journey of improving the inputs to the structure – making better choices about what problems to solve.
A Good Problem Statement has Four Elements
- A definition of the problem we intend to solve – this is the “why” of our product or enhancement.
- Identification of the users who are affected by the problem – this is the “who” of our product.
- Identification of the consequences of leaving the problem unsolved – this is the “pain” we are addressing with our product.
- An Imagining of a future where the problem is solved – this is an envisioning which provides multiple benefits in both completeness and correctness.
These four elements are important because we need our executives to align around concrete purpose – achieving a shared understanding of the problem, why it is important to solve, and what good enough looks like. When teams do work which does not advance the solution of the identified problem, that work is waste. When teams do more work than is needed to solve the problem, that work is also waste. A well structured problem statement helps prevent both irrelevant features and gold plating.
When we activate our teams to “build the things” we are introducing waste because those things are always misaligned to the problems we need to solve. It is critical, we instead align our teams around solving the problems. The appropriate things to build will be discovered when it is appropriate. And the things we choose to build can be easily changed when we realize different things are required. All without changing direction – we are still focused on solving the problem.
Summing Up
- When we organize around the problems we choose to solve, instead of the solution ideas, we more effectively activate our teams, eliminate waste, and deliver predictably.
- Epics represent investment decisions to realize value (to ‘solve the problems which prevent realization of value’).
- Problem statements help us in choosing the right problems, and help us in aligning our problem choices with our strategic intent.
In future articles, I hope to write about applying techniques (like using “How Might We?…”) to improve the problems we choose to solve. For now, we can all realize the systemic benefits which arise from using this approach to describe the problems we have chosen.
Published on Java Code Geeks with permission by Scott Sehlhorst, partner at our JCG program. See the original article here: Epic Problem Statement Opinions expressed by Java Code Geeks contributors are their own. |
I appreciate you providing this wonderful knowledge so much! I look forward to reading more of your blogs. I like coming to your website.