More of a methodology question than an Anaplan question. Is a traceability matrix required or a part of The Anaplan Way (or Agile)?
What an awesome question. I can tell by the question you've implemented a lot of solutions.
In the Anaplan Way course I took, a traceability matrix was not mentioned; but, as a good practice, I would highly advise having one, especially if there are multiple modelers and/or if the user-stories are complicated. This is particularly true when it comes to data transformations.
Honestly, I've found some of the best documentation you can create as it relates to traceability are the "sources" of data. It can become very hard to determine (or even remember) where the data came from originally. While most people will probably tell you to document your sources in the "notes" section of your actions, I found it very hard to get everyone to adhere to a common way to document that (plus, you don't get a lot of visible space in the notes). When you get up to about 30 actions (i've seen some with over 200) you have to have a systematic way to document the sources. You will definitely encounter this when you start implementing multiple applications together as part of the the connected planning process.
To keep track of changes, I have implemented two different strategies. You might try one or create your own.
1. Use the Anaplan Way application - free download from the app hub. It takes some time to get used to it but it actually serves two purposes. One, it follows the Anaplan Way methodology and documents as you go. This is great with the user stories. Plus, there's really good online training on how to use it. The second purpose, is more selfish. You will see some AMAZING things you can do with Anaplan. Honestly, I think I learned most of my tips/tricks from that app.
2. You can build your own Excel interface and manage your traceability matrix there. While this isn't best practice, sometimes you have to be more practical. I have even interfaced Excel to the Anaplan Way app. From PowerPoint, I use PowerPoint-VBA to read my Excel sheet and make very appealing slides for each user-story. Now, there's even a built in interface in PowerPoint to Anaplan. I haven't tried that but I suppose that might work too.
Let's keep the conversation going! What specific use-cases are you thinking about as it relates to a traceability matrix?
Hello @Joshua.Huilar ,
Anaplan way has the RTM (Requirement traceability matrix).
In Anaplan Way, User stories represent the Requirements.
If you carefuly look at the contents of user story, there is a field called "Acceptence Criteria". It is nothing but a description of how the user story can be tested. So each user story must have one or more ways to test it completely.
UAT test cases must be a mear compilation of all "Acceptence criteria". More detailed acceptence criteria the better for complete and quality testing. We must insist users to write the user stories with complete details in "Acceptence critieria".
@JaredDolich and @ArunManickam thank you for the responses!
Regarding use cases, at my previous firm my primary focus was on FP&A (across numerous industries) and S&OP (e.g. demand planning, production planning, MRP, etc.) solutions. At my current firm the focus is on FP&A for financial services companies.
Project deliverables at my previous firm included user stories with acceptance criteria and test scripts, which would be created by the client and tracked via a project management tool (e.g. JIRA or TFS). At my current firm we have those same deliverables but also a traceability matrix. Some online sources stated that traceability matrices are typically not included in Agile as one is typically covered via the user stories and test scripts. Overall, I feel the traceability matrix may be redundant to normal Agile, but to your point, perhaps there is a benefit to having it on more complex projects.
Regarding using the Anaplan Way application from AppHub. At my last firm we used a separate project management tool because the firm implemented other services outside of Anaplan. This would enable a standard approach to track projects across multiple practices. At my current firm, typically the client dictates we use the client's existing project management tools. I agree that the Anaplan Way application would have some good tips and tricks to use, and that having the client update their project deliverables in the Anaplan Way application would give them more exposure to Anaplan and hopefully shorten any learning curve time.
Regarding creating user stories in Power Point. I've seen projects with 100+ user stories, so I feel like a project management tool like JIRA or TFS would serve the same purpose as Power Point. On average, how many user stories do your projects have that you would then create in Power Point?
Speaking of user stories. It'd be nice if Anaplan provided standard user story templates understanding that they will cover 80% of client requirements and there will always be another 20% that will have to be further defined during requirements gathering with each client. At both firms, I've observed user stories always being created from scratch and many clients asking if there are standard user stories that we can start them off with. I myself have attempted to draft standard user stories and garner feedback from my broader teams to supplement those as needed.
I am cognizant that many firms are trying to establish their own value proposition to prospective clients, but for example, headcount and opex planning are relatively the same regardless of the industry or size of a company. For that, I think there should be standard user stories similar to the scoping scripts that Anaplan provides.