Customer Success: Writing a Winning User Story that Improves Employee Adoption of New Technology

PeerCulture, January 17, 2017
Sign up for
monthly trends,
highlights &
peer reports

Amazing new technologies come out every year that help employees work smarter and more efficiently at work. When a new technology is introduced within the organization, there are promises of streamlined processes, decision-making support and improved results with the belief that employees will be happy, excited and ready to jump right into a new way of working. However, that is rarely the case. Employees often resist new technologies at work because they are comfortable with their routine or they feel they are doing just fine without the new software. Change is difficult, especially when the perceived benefits don’t directly connect with the end user. What is the direct benefit to me?

Companies will try many things to get employees to adopt a new technology. They will incentivize or create company-wide games that integrate the technology. Sometimes this works for a small sample within the organization, but company-wide adoption is still a huge challenge. To that point, we were wondering what it is like to be the person in charge of helping a company adapt/adopt. What is the experience of implementing a new technology? What are the push backs and how are these issues overcome? What is the key to a successful implementation and retention program?

To help us better understand this world of technology adoption, we caught up with Tyler Philpot. Tyler is a Delivery Manager at Bluewolf, an IBM-owned company and global strategic partner of Salesforce. He manages a team of consultants specializing in helping large corporations get the most of their Salesforce implementation.

So Tyler, you see the challenges of employee adoption all the time. What is your experience and how do you find success?

Build it and they will come, right? Wrong. A business manager cannot expect their employees 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, i.e. it provides new, needed functionality or it 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.

The user story = a simple yet effective way to organize one’s thoughts and prioritize features. As a [blank], I want [blank], so that I can [blank]. This simple syntax captures the persona, the need, and the purpose in one sentence. Because a project is just the sum of its features, it makes sense to break it down into granular elements instead of trying to boil the ocean, so to speak.

Some best practices on capturing and using user stories:

There should be no mention of a solution in a user story, i.e. it should only capture the who, what, and why (not how). 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 one fails to properly identify the persona. (What kind of manager benefits from this?) It is overly prescriptive by containing a suggested solution. The suggested solution may not be the most elegant one. Finally, it fails to capture the actual business outcome. (Why is sending surveys important?) The second story tells me a specific manager needs CSAT information for the purpose of continuous improvement.

User stories should be specific to a single piece of functionality or feature so that “user story” and “feature” become synonymous. Not all features are created equal so some may be selected for development while others are put on the shelf for future consideration. 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 into 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,” which means you would want to prioritize them separately. Having one user story for each would allow for easy prioritization.

Because business users are typically the ones using the solutions, they should absolutely be involved in creating user stories (or at least validating them). It’s almost comical how often the IT and Business organizations have completely misaligned expectations for a project. Business needs to be intimately involved throughout the process to validate that the desired business outcome is captured correctly and expectations are shared with IT, who will likely be responsible for supporting the project.

Each user story should have a value associated with it so that it can prioritized properly. There are many ways to assign value, e.g. a numerical score 1-10. Imagine a simple, 2-by-2 matrix with Cost on the y-axis and Value on the x-axis — features with high value and low cost are a great place to start. Any feature that is not absolutely required for a “minimal viable product” should be subjected to such a cost-benefit analysis.

In essence, your projects will be more successful if you continuously empathize with the end users and capture their needs via user stories.

Bluewolf, an IBM company, is a global consulting agency that builds digital solutions designed to create results. Now.