Consulting companies like PowerObjects often use a predefined methodology during Microsoft Dynamics CRM implementation projects. We do this because good methodologies provide a roadmap and best practices to guide the project team.

Most methodologies for implementing packaged software are primarily based on a traditional waterfall model.   This model is a set of sequential processes contained in phases such as Analysis, Design, Construction, Testing, Deployment and Maintenance that represent a single release of software.

The length of each phase is based on the amount of work required to complete a set of agreed upon features or requirements for each release.  Each subsequent release requires the project team to start the methodology over again from the beginning.   When implementing Microsoft Dynamics CRM, project teams will meet with each business unit to analyze their business requirements in full before starting to design or build the solution.  Once the requirements have been identified, the team will move on to designing, constructing and deploying the system.

More recently, software developers and consulting companies have begun using a more iterative approach to implementing software like Agile Development.  Agile can be traced back to the early 1970’s but has become more prevalent since the introduction of derivatives like Scrum and Extreme in the late 1990’s.   Before we can dive into CRM and agile development, let’s take a deeper look at Scrum.

Scrum

The Scrum methodology is based on three concepts; short iterative build/deployment cycles called "Sprints"; self-directed and empowered project teams and minimal documentation. Like Waterfall methodologies, requirements are gathered through interviews with business owners and requirements gathering sessions. The deliverables from these events are captured as "User Stories". User stories are business requirements from the user's perspective. For example, a typical user story is written as "As a sales rep, I would like to store customer information so I may quickly retrieve it at a later date before meeting with the customer". The User Story also contains the acceptance criteria as defined by the business. For example, the acceptance criteria in our previous example would list the fields needed to store customer information. The user story also contains the test cases needed by QA to determine if the software meets the acceptance criteria.

Releases

Scrum projects consist of releases and sprints. Sprints are short two or three week work windows and a release is a collection of sprints. Prior to the first sprint, the project team will conduct user interviews and build a collection of user stories called a product backlog. This is often called Sprint 0. For more extensive projects, the requirements gathering process can be lengthy and occur prior to Sprint 0. Some project teams will utilize alpha sprints such as Sprint A or Sprint B and place all requirements gathering activities into these two or three week long alpha sprints. At the end of Sprint 0, the project team will point the product backlog

Planning (Scrum) Poker or Pointing

Pointing, also known as Planning Poker, is a process in which the members of the team assign a point value to each user story. Points are a theoretical representation of the effort needed to complete the user story. Points don't represent time, but rather the combination of work, risk and complexity. Each member of the team is asked to point the user story simultaneously. Team members who point lower or higher than the group consensus are asked to explain their score. The objective of pointing is to reach team consensus regarding the user story and to hear the concerns of each team member.

Once the product backlog has been pointed, the business owner is responsible for placing user stories into individual sprints based on the needs of the business. The number of users stories contained in any given sprint is based on the total number of points. Mature sprint teams, can often work on Sprints with 150 points or more. Prior to the start of each sprint, the project team repoints the user stories contained in the sprint. This is required as the project team learns throughout the process and a user story may become easier or more difficult once prior sprints are completed.

Sprints

Each sprint consists of the following activities: Planning, design, development, testing, acceptance and demonstration. The idea is to develop small chunks of software, demonstrate it to the business and move forward. This allows for continuous improvement while reacting to the changing needs of the business.

Reports

Agile projects use a variety of reports to track the project's progress. One such report is the Task Progress Report. At the beginning of each sprint, team members are responsible for entering tasks for their assigned stories. Throughout the project, each member of the team will close out a task as soon as they are finished with the required work. The Task Progress Report shows the total number of tasks and how many are closed, in progress and active. As you reach the end of the sprint, the number of active and in progress tasks start to reduce. This is also called burn down. Any tasks and user stories left unfinished at the end of the sprint get pulled out of the sprint and moved to a future sprint.

CRM and Scrum

So now that we know a bit more about Agile and Scrum, how would you use this methodology to implement Microsoft Dynamics CRM. We can use 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.

CRM Pre-planning and Sprint 0

To build the product backlog, the project team would interview each user group to gather their requirements. This is a similar approach to the analysis phase of the waterfall methodology. The requirements would 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 prioritize the users stories into future sprints.

Sprint 1

Sprint 1 is the perfect sprint for configuring the servers, installing the software and setting the base security rules. All of these tasks must be accomplished before the project team can move into development.

Sprint 2

Since Accounts are one of the fundamental CRM Entities and we have completed some of the server and security work in Sprint 1, we will start Accounts in Sprint 2. The users stories for accounts would include stories that would translate into tasks for 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 Act accounts so I can view them in Microsoft Dynamics 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 3, 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 CRM". 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 2, you would demonstrate full Account functionality or even deploy Accounts to your users.

Sprint 3 – 5 Contacts, Activities and Opportunities.

Each subsequent sprint would handle another CRM entity. In Sprint 3, we will move to Contacts, Sprint 4 would be Activities and Sprint 5 would be Opportunities. Each sprint builds on the code written in previous sprints.

Sprint 5 – Firming

The idea behind firming sprints is to catch up on issues, bugs or refined requirements that the project team encounters during previous sprints.

Sprint 6 – 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 a Microsoft Dynamics CRM implementation 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. To learn more about Agile development and Scrum, please visit the Scrum Alliance @ http://www.scrumalliance.org/ or the Agile Alliance @ http://www.agilealliance.org/

Happy CRM'ing!