User Stories by Building Blocks of Anaplan
For each business process that is documented, it should have at least one user story that falls into each of these building blocks.
Library:
Define Lists: These are the user stories that hold the meta data of the model. Think in terms of the word “by”. For example: I want to see inventory counts by Depot, by Site, by SKU… or I want to see Salaries by Company, by Department, by Cost Center…
Each time I use the word “by” in my description, that is a good indicator it should be a list and I will need a user story to create that list.
For each List it is not uncommon to have 2 User Stories – 1 for the creation of the List, and 1 for the population of the list elements, especially if the items on the list come from a system source.
Engine:
INPUT:
Data Integration: These are the user stories that describe the data that we want the system to pull into Anaplan for us. These will describe the source table fields that we want to include in our query for this data, the filters or criteria we need to get the correct information that is relevant for our model.
BUSINESS PROCESS:
User stories describe how the data pulled in from system sources is added to or feeds into business calculations that drive the process. These are often identified by specific screens in other applications or tabs within excel models. Each screen or tab or even section of a tab can be a user story.
For example, creating a revenue forecast that includes the following steps:
- Pulling the demand from data loaded into Anaplan
- Pricing Manager updates price by product
- Calculating the expected revenue by multiplying updated price by units loaded
Each step in the revenue forecast process could be a user story.
These user stories generally describe what will become modules within Anaplan. For modules, it is not uncommon to have 3 User Stories – 1 for creation, 1 for population of items from outside, and 1 more for calculations in the module.
Experience:
Administration Dashboards:
These dashboards are designed to facilitate model maintenance with updates to lists, manually execute global processes or set global assumptions. These dashboards are generally utilized by a limited number of users who are responsible for model structures and updates from system sources.
User Dashboards:
These user stories describe how the user will see the business calculations described in the Engine user stories or how they would like to contribute data if needed to make the business calculations work. There may be user stories that map out the process flow and provide navigation buttons to other dashboards with directions to assist the end users. Dashboards should be designed to make it easy for users to contribute data needed for the business calculations.
Reporting Dashboards:
These user stories describe how they would like to analyze the results of the business calculations and see graphical representation of data. These dashboards are generally not designed for heavy user inputs.
Answers
-
Have a read of The Anaplan Way on how user stories drive our Connected Planning approach.
2 -
The three key components- Lists, Engine and Dashboard – identified in your post are great. Focus on those components will help drive out the necessary details needed for user stories. These components are mostly model builder thoughts when thinking about how to build the user story. As user stories are created with the business owner or business SME, the user story should be related to a business function or capability required in the overall business process. In the Anaplan Agile App the User Story Detail dashboard has a top portion of the user story for the business to complete – Who, What, How and Why. The business team will document the initial description of the user story as well. And the Description box is where I think the three key components you identified in your post would be entered.
The evolution of the user story starts with the business team defining a portion or capability of a business process with the four initial boxes on the User Story Detail dashboard. Then as the user story is groomed the solution architect or model builder will work alongside the business team to add more and more details to the Description field. This is an iterative process that drives out all the details within the three key components identified in your post.
I would like you to consider one more key component for user stories. The business team will need to define the acceptance criteria for the user story for the user story to be complete. The acceptance criteria are the final key component I would add to the three components you identified. The business team must define how they will validate the model build. The acceptance criteria will be the basis for later development of the test scripts for verification and test. Then the bottom portion of the dashboard within the Anaplan Agile App is for the model build team to track the user story from sprint planning through the build.
3 -
Background: During foundations or requirements gathering we always emphasize that the client should create their own user stories. We typically share "User Story 101" information in several slides within our project kickoff deck; however, it may be more effective to have the client watch a short 3-5 minute video on explaining what User Stories are.
Question: Is there an Anaplan video that provides an overview of User Stories?
I found a good link to a User Stories write-up under the "Sprint Planning" section of the "The Anaplan Way" guide (https://community.anaplan.com/t5/The-Anaplan-Way-Guide/ct-p/The_Anaplan_Way_Guide), but I still feel a quick video would help clients better understand the ask and the importance of user stories.
0 -
Hi Joshua - There is not a video that I am aware describing writing User Stories. We usually use several slides at kickoff as you mentioned in your post. The Agile App is what we typically use to get the customer going on user stories since user stories in the Agile App are built using the core components of a User Story - Who, What, Why and How. If we work with the customer to create the first couple of user stories together in a workshop, then the customer can begin to create user stories on their own. We typically give the customer some homework for a few hours then come back together to groom the details. After several iterations of homework and grooming workshops, the customer can create user stories. The Solution Architect (SA) is critical to work side-by-side to create user stories that fit the design and requirements of the model being built. The customer provides the business aspects and the SA provides the Anaplan aspects. Jointly creating user stories is the best practice!
3 -
This content has been removed.
-
This content has been removed.
