1. Be the User
On the surface this sounds easy. In practice, it can be much more difficult. Let’s face it, U.S. healthcare is complicated. At the highest level there are providers, payers, subscribers, patients, employers, and brokers. Each of these groups can be further broken down into sub-groups. With all of these potential users it is crucial to have the right user focus. To illustrate, a provider portal application may need to support doctors, nurses, front-office staff, office managers, vendors, and consultants each with unique user requirements. To help stay on track developing several personas that represent typical classes or categories of application users can be helpful. Below is an example of a persona that reflects a power user of a provider portal application. Personas are not intended to be actual people so have fun when creating them. It is helpful to throw in interesting facts to make the persona easier to remember. In the example below, our team remembered this persona as “the girl that won the lottery and lost her ticket”.
Pro Tip: Read through a persona and really put yourself in their shoes when writing or reviewing user stories.
2. Don’t Get Tripped Up if the User is a System
At some point, you will likely find yourself creating user stories with no users. Imagine a story for sending an 837I EDI claims transaction from a hospital to an insurance company. This would likely be an overnight batch event with no user trigger. Additionally, the transmission of the message and the 997 confirmation would not require any human interaction. These stories should be written from the system’s point of view, “As a healthcare billing system, I would like to properly format an 837I claims file and transmit it to XYZ clearinghouse for downstream processing.”
Pro Tip: Don’t hesitate to attach an Excel file to your story. If your story is a target system receiving data from a source system in a certain format then attach the message format and provide example messages. This will help convey details to the development team and spur fruitful discussion during backlog grooming.
3. Become an Expert at Vertically and Horizontally Slicing Stories
Because of the tremendous complexity in healthcare systems, one will likely encounter scenarios where vertical and horizontal application layer slicing is required to breakdown stories. Vertical slicing allows you to limit the user or system to very specific scenarios, but includes development of all application layers. Horizontal slicing, on the other hand, involves limiting development to a particular layer of the application and will likely not result in full application functionality, but may allow the user to view a complete picture of a given application layer.
Consider the following examples and how we might use horizontal and vertical slicing to break the story down into smaller stories.
- As an HL7 interface engine, I would like to process a patient registration message (ADT A04 v2.3) into the core database so that downstream systems will know the patient has been registered at the facility.
- Vertical slicing – One way to vertically slice this story is to limit the story to succesfully parsing and storying just a particular HL7 message segment such as the PID (Patient Identification) information. Note that the other elements of the transaction may be needed for the interface to successfully process the message but these elements (i.e. MSH, EVN, PV1) wouldn’t be part of the success criteria for the story
- Horizontal slicing – Another option is horizontally slicing the story to to only process the required messages segments while removing any focus on network transport protocol (i.e. FTP) and any storage in the database. This would require flexibility during the testing process which may need to key on interface logs rather than database tables.
Pro Tip: Story slicing requires creativity and can often be accomplished by sitting down with the development team and drawing out an approach that works best. There are many considerations including test approach, technical rework, and user experience.
4. Work on User Stories that Align with the Product Strategy and Provide the Greatest Value
It is important to have a clear strategy that is well understood by the agile teams working on a given product. In healthcare, products often serve multiple user groups and this makes forming a cohesive product strategy more complex and challenging. It can often take a focused effort to develop and maintain a product strategy that accounts for all stakeholders. Once the strategy is documented it should be published so that all agile team members can review it.
When it comes to assessing the value of a user story many agile teams use a method of ranking via a value or priority score. Assigning this single value or priority score can be subjective. It is better to think through the components of a value score and attempt to build a small custom survey that will help calculate the score more objectively based on key areas of value that the product owner and team find important. Consider the sample survey below.
In the example survey above, a custom rating scale is used to calculate a total value score for the user story. By breaking the value score into components, the team is forced to think about each key value area when determining the total value of a story. This can help the team achieve a more objective value score. Another option is to conduct these value surveys at the feature or epic level as doing them for each user story may be too cumbersome. In this case, the user stories could inherit a value score from the feature or epic that they reside within.
Pro Tip: Team’s may want to include numeric reference points in the survey metrics rather than using relative ratings. As an example, the Return on Investment rating in the survey above could be a sliding scale from 2% to 20% rather than a relative 1-10 rating.