Build it and they will come, right? Wrong. A business manager cannot expect employees or customers to adopt a piece of technology simply because it was built. People use business applications for two reasons: 1) it's required for their job role or 2) it's actually helpful, e.g. it provides new functionality or allows users to do current tasks more efficiently. It should be no surprise that applications are adopted more completely when empathy for the end user is a constant during each stage of the project lifecycle -- starting with user story development.

Here are our best practices for capturing and implementing user stories:

Writing the Story
The user story template is simple: As a [blank], I want [blank], so that I can [blank]. It captures the persona, need, and purpose in one sentence. Avoid mentioning a solution in a user story and focus on the who, what, and why (the how comes later). Compare the following:

• As a manager, I want a Contact lookup field on the Project record so that I can send Customer Satisfaction Surveys to that person.
• As a customer service manager, I want a way to solicit CSAT surveys so that I receive feedback on how I can improve customer service.

The first example fails to identify the persona, is overly prescriptive, and fails to define why sending surveys is important. The second story is direct and informative; it tells me a specific manager needs CSAT information for the purpose of continuous improvement. A properly written user story eliminates guess work and empowers the project team to design the best solution for the right people.

Be Specific
User stories should be specific to a single piece of functionality or feature so that "user story" and "feature" become synonymous. Multiple functions in a single story can create confusion down the line. Consider the following:

• As a project manager, I want to be able to specify a project's "health" as being Green, Yellow, or Red, with a corresponding image of each value so that I can see which projects need the most attention.

This example contains two features: a way to segment accounts three levels of health and a RYG image depicting that health. One could argue that the first is essential while the second is a "nice to have," but without separation and clear prioritization, the project team may end up working on the wrong things at the wrong time. 

Align Business & IT
It's almost comical how often the IT and Business organizations have completely misaligned expectations for a project. As the end users, those on the business side need to be intimately involved throughout the process to ensure the desired outcomes are captured correctly. They are also responsible for sharing those expectations with IT, who will support and execute the project. 

Prioritize Your Features
To help you prioritize your features, assign a value to each user story. Imagine a simple 2x2 matrix with Cost on the y-axis and Value on the x-axis -- features that are high-value and low-cost are a great place to start. Grade your results on a scale from 1-10 and prioritize those at a 7 or higher. Any feature that is not absolutely required for a "minimal viable product" should be subjected to this type of cost-benefit analysis.

Your projects will be more successful if you continuously empathize with end users and capture their needs via user stories. By clearly defining the audience, need, and desired result, your applications will have more impact and higher adoption rates, making your teams and your business more successful. 

For more tips on how to understand and connect with your employees and customers, register for our upcoming webcast "How to Bring Customer Obsession to Life in 2017."