The Role of ServiceNow Stories (STRYs)
In the realm of ServiceNow development, the Story (STRY) serves as a crucial communication tool between users or stakeholders and developers. It outlines the intent, functionality, and user experience expectations of a particular service or feature. However, crafting an effective STRY requires a balance between user perspective and technical clarity to ensure smooth implementation and maintain platform standards.
The Importance of Clear STRY Writing
Anyone can write a STRY, but clarity and specificity are paramount to its effectiveness. A well-written STRY not only articulates user expectations but also provides developers with clear guidance on implementation details and platform standards. This ensures that the end product aligns with user needs while adhering to technical constraints and best practices.
The User's Perspective
A user-centric STRY begins with the user persona and articulates user actions, interactions, and expected outcomes. It paints a vivid picture of the desired user experience, guiding developers in creating intuitive and user-friendly solutions.
Example of a User-Centric STRY:
"As a Service Desk Agent, I want a new incident form that streamlines the process of logging and categorizing incidents.
I will consider this complete when I can easily fill out the incident form with relevant details such as category, priority, and description. The form should anticipate common issues and provide dropdown menus for quick selection. Upon submission, I expect to receive a confirmation message and see the incident logged in the system."
The Developer's Perspective
From the developer's standpoint, a clear and detailed STRY provides essential technical guidance, including data structure, terminology, and platform standards. It minimizes ambiguity and reduces the risk of misinterpretation or deviation from established practices. A ServiceNow developer would need a STRY that clearly defines the data model and field mappings for the new incident form.
For example, the incident form should be based on the 'Incident' table and include the following fields: Short Description, Description, Caller, Category, Priority, and Assignment Group. Field types and attributes should align with ServiceNow best practices. Additionally, the form layout should follow the standard UI design patterns for consistency across the platform.
Clarity vs. Ambiguity: A Comparison
Let's compare two STRYs—one characterized by ambiguity and lack of detail, and the other by clarity and specificity.
Ambiguous and Vague STRY
"I need a new feature for logging incidents in ServiceNow. It should be easy to use and look good. Please make it happen."
In this example, the STRY lacks specificity and fails to articulate clear requirements or expectations. It leaves room for interpretation, leading to potential misunderstandings and inconsistencies in implementation.
Clear and Specific STRY
"As a Tier 1 Support Agent, I need a new incident form in ServiceNow to streamline incident logging and classification.
I will consider this complete when I can easily access the 'New Incident' form from the ServiceNow dashboard. The form should include fields for Incident Category, Priority, Description, and Caller. Upon submission, the incident should be assigned to the appropriate support group based on the selected category."
This example provides better user context, desired functionality, and expected outcomes, enabling developers to translate user requirements into actionable tasks with minimal guesswork.
Enhancing STRY Writing with Additional Context and Examples
To further enhance the effectiveness of STRY writing, it is beneficial to include additional context and examples. This can involve providing background information about the user's environment, the business processes involved, and any constraints or dependencies that need to be considered.
Example of Enhanced STRY:
"As a Tier 1 Support Agent, working during peak hours when incident volumes are high, I need a new incident form in ServiceNow to streamline incident logging and classification.
I will consider this complete when I can easily access the 'New Incident' form from the ServiceNow dashboard. The form should include fields for Incident Category, Priority, Description, and Caller. It should also provide predefined templates for common incident types to expedite the logging process.
Upon submission, the incident should be automatically assigned to the appropriate support group based on the selected category, and I should receive a notification confirming the assignment."
Incorporating Technical Specifications and Constraints
In addition to user requirements, including technical specifications and constraints within the STRY can help ensure that developers have all the necessary information to implement the solution effectively. This might involve specifying data validation rules, integration points with other systems, and performance considerations.
Example of Detailed Technical STRY:
"The incident form should be based on the 'Incident' table and include the following fields: Short Description, Description, Caller, Category, Priority, and Assignment Group.
Field types and attributes should align with ServiceNow best practices.
Validation rules should ensure that mandatory fields are not left blank and that the incident priority is set according to predefined criteria.
The form layout should follow the standard UI design patterns for consistency across the platform.
Additionally, the form should integrate with our CRM system to automatically populate the Caller field with customer data based on the caller's email address."
Conclusion
Effective STRY writing requires collaboration between users/stakeholders and developers to ensure alignment of expectations and technical feasibility. By adopting a user-centric approach while providing clear technical specifications, organizations can enhance communication, streamline development workflows, and deliver user-centric solutions on the ServiceNow platform.
Remember, the clarity of a STRY not only influences the success of individual projects but also contributes to the overall efficiency and effectiveness of all ServiceNow implementations in the pipeline. Reworking a product can steal valuable time from your ServiceNow team and cause other developments with dependencies to slide. This can lead to a backlog of work and delay the delivery of critical features and improvements.
By investing time in crafting detailed, clear, and comprehensive STRYs, organizations can ensure smoother project execution, higher-quality deliverables, and better alignment between user expectations and technical implementations. At BlueprintSolutions we have strong recommendations on what is expected of vendors submitting STRYs for development. If you would like to hear more about these standards, reach out to us via our contact page.
Comments