by Business Analysis (BAPL)

The transition to Agile for Dynamics 365 or CRM methods is revolutionising enterprise software projects. Agile projects offer faster deployments, reduced costs, higher quality, more satisfied users and stakeholders, and more fun for the project teams involved compared to traditional, waterfall methods.

But how would one use this methodology for CRM projects? Let me help you with my experience as a BA in the implementation of CRM projects using Agile.  First and foremost is to understand what functionality of the CRM needs to be implemented to meet business needs and processes. For instance, a few of the services Microsoft Dynamics CRM provides functionality for are:

 Image courtesy of: https://www.powerobjects.com/services/dynamics-365/

So, which of these are relevant to addressing the business need(s)?

Once we understand the CRM functionality to be used, the next steps are understanding the data, business processes and entities to be used in the CRM. Let us take an example of a standard Salesforce Automation (SFA) project as a guide. With SFA projects, the typical user constituencies include inside sales, outside sales, sales assistants and management. The standard CRM entities to implement would include Accounts, Contacts, Opportunities, and Activities as a minimum. In addition to the entity development, there are often workflows, data migration tasks and reporting requirements as well. Let’s see some of the activities of a BA working in an Agile environment on this type of project.

CRM Pre-planning and Sprint 0

To build the product backlog, the BA, along with the project team, could interview each user group to gather their requirements. This is a similar approach to the analysis phase of the waterfall methodology. The requirements should be documented as user stories with acceptance criteria. The user stories would include requirements relating to data entry, searching, data conversion, integrations, workflows and reporting. At the end of Sprint 0, the project team along with the business owner would prioritise the user stories into future sprints. Sprint 0 is the perfect sprint for configuring the servers, installing the software and setting the base security rules. All these tasks must be accomplished before the project team can move into development.

Sprint 1

Since Accounts are one of the fundamental CRM Entities and we have completed some of the server and security work in Sprint 0, we will start Accounts in Sprint 1. The user stories for accounts would include stories that would translate into tasks for storing data, creating forms, creating views, data migrations, reports and workflows. For example, the user story might say, “As a sales rep, I would like to save information about companies I am selling to inside CRM”. The user story would detail the fields such as account name, account number, physical addresses, billing address, phone numbers, etc. A second story would describe any data integration or importing requirements. For example, “As a sales rep, I would like to convert my existing accounts, so I can view them in the CRM”. It is important to remember that you wouldn’t be able to include stories about contacts until those entities are created in future sprints. So, if we included contacts in Sprint 2, we could include a user story that establishes the relationship between the account and contact in sprint 1 or future sprints. For example, “As a sales rep, I would like to associate a person with the company they work for and store this information in the CRM”. I have found ER diagrams very useful to depict the relationship between the entities.

For data migration tasks, the activities would be limited to the fields identified in the user stories for Accounts only. At the end of Sprint 1, you would demonstrate full Account functionality or even deploy Accounts to your users. Another important role of a BA in each sprint is firming. The idea behind firming sprints is to catch up on issues, bugs or refined requirements that the project team encounters during current or previous sprints.

Sprint 2 – 4 Contacts, Activities and Opportunities.

Each subsequent sprint would handle another CRM entity. In Sprint 2, we will move to Contacts, Sprint 3 would be Activities and Sprint 4 would be Opportunities. Each sprint builds on the code written in previous sprints. A BA keeps grooming the stories for next sprints and plans showcases for each sprint to get the feedback from the business.

Sprint 5 – Deployment

If the project team did not deploy at the completion of individual sprints, you can always add a deployment Sprint as part of your initial release.

Conclusion

The benefits of Agile (Scrum) development for CRM implementations are the iterative nature of short sprint cycles. Changes in business processes or new requirements can be quickly implemented by the project team without the need to wait for the “next” release. In addition, the short development cycles also tend to expose risks and issues earlier in the project as opposed to later development phases.