Go Agile With Market-Driven User Stories

By Johnathan Lucky
April 12, 2017

Getting a product to the market is hard. You might think that the hardest part is building the…

Rate

Getting a product to the market is hard. You might think that the hardest part is building the product itself, but I think the most challenging part is deciding what to build in the first place. Specifically, articulating what to build and why it’s important. For some product people, agile makes articulating requirements even harder. However, responding to change and breaking big things down into small things is exactly what we must do to deliver products the market will love as early as possible. And so I believe that agile is an opportunity to connect to the market, strengthen product requirements and get buy-in.

How do we accomplish this?

  1. Listen to the market. Understand the problems, their pervasiveness and the context around these problems.
  2. Turn that understanding into concise, relatively large problems and prioritize them.
  3. Collaboratively break those problems down into user stories that the team can build.
  4. Organize your problems and stories into a flexible problem-oriented roadmap that ideally targets specific personas with each release.
  5. With each iteration big and small, funnel feedback into your roadmap as new problems or stories.

To start, get out of the office and engage with buyers and users in the marketplace. Interview them to find out what makes them tick, what keeps them up at night, what they read and who they follow. Pragmatic Marketing calls these NIHITO Visits (nothing important happens in the office). This activity will give you qualitative data that you can validate quantitatively through surveys and market analysis. Take these learnings and build personas, the representatives of your market.

Armed with market facts, you can now define the problem. Analyze your market data and personas, and look for patterns among them. These patterns will reveal market problems that are both urgent and pervasive. Write problem statements that describe the issue and include the emotional cost to the user and the frequency. Using your NIHITO visits, tally the number of times you have witnessed this problem in the market (be prepared to have examples in case you are challenged by stakeholders). Rate the business value of the market opportunity to your customers, and compare it to other problems you could solve.

At a previous company, we knew we needed to rebuild of our flagship product. Prior to development, we spent months interviewing potential and existing customers to discover the problems with our existing tool.

We discovered that it was a huge pain for our veteran users to use the wizard every time they set up a new job. We had thought the wizard would be a great way to ensure that users ticked all the boxes, but we failed to realize that it forced users to do things they didn’t need to do. We communicated the issue to the wider development team and collaboratively approached our user stories with this problem in mind. The result? We focused our user stories on keeping options open to the user, but not mandating them.

Getting feedback on working software is important in agile. We tested an early prototype on a small group of new and veteran users. We gave them a broad description of the goal and asked users to set up jobs. As we watched nervously, we learned that when we removed too much guidance from the process, both new and advanced users got lost. They enjoyed the open interface that allowed them to access the features that matter most to them, but whenever they set up new jobs, they didn’t know where to start or what to do next. 

To strike a balance, we implemented a checklist that gently coached each user on what to do next without forcing them down a specific path. We implemented this into the next iteration; our focus group tested it and loved it. 

So why didn’t I just tell development the solution I wanted built? Articulating problems rather than features frees engineers and designers to choose the right technology and design to solve the problem.  Moreover, you have no idea if a feature is suitable for the market unless the users actually use it. Articulating problems rather than features avoids locking the team into technology that fails to achieve user goals. Placing the problem at the forefront keeps the organization focused on solving the user’s problem rather than the tools needed to do it.

Once you understand the problem’s frequency, business value and projected effort, you can prioritize market problems with the goal of solving the most urgent and pervasive ones first.

Organize the prioritized problems into releases that target each persona. Driven by urgency and market data, the teams will first build what matters most. This roadmap makes it easy for stakeholders (especially nontechnical ones) to understand who you are targeting, why and the order, all based on market facts. This also helps sales and marketing teams develop messaging that focuses on each persona.

Market problems are big and can’t be built in a single increment. So how can you be sure that your solution will solve the problem? A major goal in agile is to take big concepts and break them down into fully functioning product increments, then adjust the plan/product based on user feedback. In scrum methodology, you could apply market problems to epics. Epics are a collection of user stories that achieve a larger user goal. You can collaborate with design and development to break the market problem down into smaller user stories that contribute to solving the problem.

Typically, user stories are structured as mini problems: As [persona], I need to [what the user needs in their words] so that I can [the solution’s benefit]. Persona documents help guide the team to make the right decisions about the user’s needs and ensure they stay aligned to the market. Though it is a collaborative effort, you are responsible for getting the stories written, prioritized and understood. 

For instance, a user story for the veteran users of the flagship product at my previous company might look like this: As Jen the IT analyst, I need to have a streamlined process that doesn’t ask unnecessary questions, so that I can set up new jobs without a lot of repetition. By attaching the persona to your user story, you provide context. 

Most agile teams work to deliver a product in small increments called sprints (typically a one-to-three-week period). The design/development team commits to deliver a collection of stories that align with a sprint goal. This keeps the team focused on solving a specific set of small problems, resulting in working software that solves the overall goal for that sprint.

Since the team delivers fully functioning, tested product increments each sprint, you can now obtain user feedback on each product increment. Review the feedback with designers and developers. Better yet, have a designer and developer tag along to watch the user use it. Turn the feedback into new user stories. As you build the product, you may modify market problems or discover new ones. Remember, the roadmap must be flexible.

Are you beginning to see how everything connects? User stories are driven by the persona’s smallest need. A collection of user stories are built to meet a sprint goal. Multiple sprint goals combine into releases that are targeted to a specific persona. Single or multiple releases combine to solve the market’s problem. 

It’s all driven by market data straight from the user. Iterating as you go, the product constantly evolves based on user feedback while still solving the primary problem. Articulating problems instead of specific technologies/features keeps the team from committing to technologies that may be incompatible with user needs based on user feedback. You free the team to select the technology that best solves the problem.Product pros can use market problems to understand the big picture while keeping tabs on the tiny details of user stories. Most important, by articulating problems and connecting them to small product increments, the team will deliver the most valuable, timely solutions to users.

Align product and development efforts to create remarkable products.

Page 1 / 1

About the Authors

  • Johnathan Lucky is head of brand and product strategy at ChristianSteven Software, responsible for leading product management and marketing efforts across the company’s product portfolio. Prior to joining ChristianSteven, Johnathan worked in the IT and television industries ranging from advertising, production and even a voiceover role for PBS. He holds a B.S. in Business Administration from the University of South Carolina Beaufort and has earned various certifications including Pragmatic Marketing and Scrum Master. Email Johnathan at johnathan@christiansteven.com or connect with him on LinkedIn at www.linkedin.com/in/johnathanlucky.


Categories:  Agile Requirements


Post a Comment

Comment

Allowed HTML: <b>, <i>, <u>

0 Comments