User Stories have become the standard way Agile teams capture requirements and were introduced almost 20 years ago as a part of XP (Extreme Programming). To put it in context, that’s four presidents and 14 iPhone models later. A lot has changed and it’s time we upgrade how we define and communicate work for teams.
Most teams are using user stories to document requirements and to align expectations between stakeholders and the delivery team. But building features with the goal of satisfying stakeholders is not good enough anymore. We should be focused on satisfying the customer.
The Biggest Lie In Product Development
The lie product departments and stakeholders tell themselves is that they know everything up front. That getting a bunch of subject matter experts in a room will allow them to make intelligent priority and scope decisions. The problem here is that most of these decisions are gut instincts that are not grounded in facts. They are “I think” or “I feel” decisions. Worse yet, these decisions aren’t validated until they are implemented and deployed into production. This is a very long and expensive feedback loop.
Also, our current requirements processes assume we actually know the right features to build. Stats show that more than half of the features we build are rarely used. Think of the word “requirement.” If something is a “requirement” it sounds like a fixed need. The statistics show us that most “requirements” are not used; therefore are not really necessary to the user. These “requirements” are really just guesses. If it’s an educated guess, then it’s a hypothesis. Maybe we should change from thinking about “requirements” to thinking about defining “hypotheses?”
The Relationship Between OKR’s And Business Objectives
We still need to have some clear goal or target. Today our goals are defined in the form of scope or the largest “epic” and then broken down into smaller user stories. But again this assumes we know the answer. Here, I think we could borrow from the OKR (Objectives and Key Results) world. What if instead of defining the “epic”, we defined the business “objective” we are trying to achieve?
Once we have a defined objective, we should engage our team to brainstorm ideas on the best way the object can be achieved and these ideas could be defined as a set of hypotheses. One way to prioritize would be for us to identify all of the “assumptions” we are making about our customers, product, market, solution, etc. We could examine the risk and impact of these assumptions and by looking at the riskiest assumptions, it might help us prioritize which hypothesis to prove first.
Agile Teams And Hypothesis Creation
We talk a lot in Agile about self-organizing teams, however, most of these teams are still focused mostly on how to best “deliver.” I think these teams should not only be focused on delivering, but also engaged in understanding the problem domain and creating hypotheses around solutions. We don’t want the product owner and stakeholder just throwing requirements over a wall for teams to implement.
We have promoted story decomposition techniques for years so that we can deliver iteratively. But too often we still wait until we have a full solution before we deploy to production and get real feedback from the market. How could we learn faster? What if we could run small “experiments” to prove our hypothesis or validate our assumptions without having to build the whole solution? The idea would be for the team to determine what is the smallest “experiment” that can be run to learn more about the problem or solution. Most importantly learning that can be validated by our customers, not stakeholders.
The emphasis of this approach would be for us to validate our ideas as fast as possible. Or is it really to invalidate our ideas and assumptions as fast as possible?
