While scoping, prioritizing and designing user stories for the Appian platform, pay close attention to the technical design and implementation of user stories exhibiting the following heuristics.
Appian recommends for the implementation teams to review their designs and approaches with Appian lead designers or Appian architects.
User Story Heuristics
Risks
Import or export of data from/to a file like Excel, CSV, flat file, etc...
Storing/caching large amounts of text data in the Appian engines.
Heap memory usage on application server.
Query more data than what is needed to be shown to the end user
Long running database query affecting UX and scalability.
Multi-step workflow assigned to the same user
Abuse of the activity chaining feature.
Application server threads "locked" to activity chains.
Application server scalability.
ETL-type user stories: data is transformed using complex logic without user interaction
Application server and engine server resource usage.
Overall impacts on performances.
Complex business logic and processing in process models
Large process models are difficult to develop and maintain.
Unattended and headless user stories
Hard to predict system load.
Potential impacts on user driven activities that compete for resources.
Functional use cases stretching over weeks/months
Long running Appian process instances.
Unscalable application design.
Complex and resource intensive process-to-process communication.
Process centric design
JMS inbound/outbound integration
Not supported on Appian Cloud.
Email inbound integration
Fragile integration patterns.
Appian to Appian integration
Siloed applications/platforms.
Complex data dictionary and data model
Complex nested CDTs difficult to create and maintain.
JPA cascading refresh and update issues.
Complex logic in process to work with nested CDTs.
Document generation
Resource intensive text manipulation.
Large volume of process instances, nodes (PM size or MNI), users, documents, data, etc...
Large resource usage.
Scalability of the solution.
Internationalization
Can add overhead and complexity depending on the use case.
“Hacking” the product
Using unsupported APIs, functions, etc. or leveraging features in a way that weren’t intended.
Not always supported by Appian Support and subject to product changes.
Event-driven architectures
Generally high-volume use cases that can lead to scaling issues if not implemented correctly.
Complex integrations
Non-modern, high-volume, and high-load integrations, or integrations with non-standard authentication methods.
Scalability of the solution, resource usage, response time, and/or security.
Use the template below to plan the design for your user story, brainstorm test cases, and gain a shared understanding with your team. This document should be reviewed by the team after the story has been groomed, but prior to beginning development. Following this template is a recommendation; however, the template can be modified as needed to fit project needs.
While there is some additional upfront cost associated with creating design documents for user stories this approach, teams have reported the following benefits:
It may be helpful to denote in-progress or completed items with formatting (for example, highlight all steps which are in progress). Any italicized text in the template can be removed. For easy tracking in JIRA, it is generally recommended that this design document be created as a subtask of the parent story to link its progress to the overall work. Upon creation, the task is assigned to a reviewer or discussed with the team prior to close-out.
View an example design document to see how this template can be used.
[Link to Story] Story Name
To be completed by the developer:
Design
Provide a design for the functionality needed for the user story, which may include the data model changes, integrations, interface, or process model changes. Include database definitions, pictures, or mockups where necessary.
High Level Summary:
Detailed Notes:
Unit Testing
Prior to development, identify valuable test scenarios not explicitly stated in the AC. These should be informed by the story design and the risks it will introduce. Scenarios should be reviewed and added to by the team before development starts to get fuller test coverage on areas of risk.
Note: For more standard test cases that are described in the AC, the developer can generally refer to the ACs or copy them with slight modifications for clarity, rather than spending time re-writing the AC in a different format.
To be completed by the peer reviewer:
Peer Review
Depending on your project, you may choose to put this information in Jira, or whichever ticket tracking tool your team uses.
Similar to how some projects use hours to estimate level of effort, story points are a relative measure of effort that encompasses size, complexity, and uncertainty. Agile projects use relative estimation to convey the level of effort needed to complete a user story.
Story points are estimates; they are not meant to be exact measures of time or complexity, but rather are an approximation of complexity, effort, and uncertainty. Estimates are subject to change, just as scope and requirements may change.
Stories should be estimated by the development team by comparing to a baseline, a simple story whose point value is agreed upon by the entire team and is referenced throughout sizing. Before estimating, the team should select several representative baseline stories. For example, a baseline story could be creating a form with three input fields and is considered 2 points by all team members.
Other tips for sizing stories include:
Velocity is the number of story points a team can complete in a given sprint. Velocity is used to identify a team’s rate of progress and scope out the release plan and future sprints. Future velocity should be adjusted based on historical performance of the team.
When estimating a team’s initial velocity, it is crucial to remove any undue optimism in order to account for distractions, meetings, and aggressive estimates. This is typically accomplished by lowering the velocity by a small number of points or adding a buffer story. It is common for new teams to take a few sprints to determine their true velocity.