The User Story Needs A Remodel. Here’s Why.

By May 11, 2017Agile, Article, Process

Cartoon of a man in a construction hat and holding a shovel, getting ready to remodel a user story.

 

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?

 

Join the discussion 3 Comments

  • Essentia says:

    Arguably, iterative cycle mimics incremental planning with its 1940’s origin traced to Charles E. Lindblom born 1917, the father of incrementalism. Adept planners understand the science of incremental development. “Rome was not built in a day,” because cosmopolitan cities are yields of conurbation. Users determine the growth of the city, not the planners. Planners provide the map, users decide what they want.
    It’s salient that Software engineering would deliver user-centric products should stakeholder satisfaction give way to users’ satisfaction.

  • One of the harder issues with OKRs is that the company OKRs are so strategic that you the break-down process to product goals or even smaler sprint goals is a very painful and not-so-straight-forward thing to do, from my experience with POs and scrum teams as an agile coach.

    Usually product strategy is not that alligned to company strategy. Someone may say: company strategy does not include the fine granularity of product strategy geared towards market segments etc.

    So, one possible approach is quit simple: start a “only vage” associated OKR at the product portfolio level. That has much more relvance to the scrum teams that allmighty company OKRs based on the overarching company strategy. U may discover that you loose some strategy alignment, but you gain a ton of clearance for the scurm teams, due to the better granularity.

    What do you thing about that tradeoff?

  • David Hawks says:

    I think we are in agreement. I was just proposing we use the OKR format/template to describe product objectives and success criteria. If they can tie into overall company OKRs great, but not required.

Leave a Reply