Ensuring Salesforce is implemented correctly within an organization is paramount to ensuring the smooth operation of the intended functions. Here are my nine tips for capturing requirements for a Salesforce Implementation or any other application:
1. Engage the Business
This might seem obvious but with many implementation projects that I have worked on in the past, there have been times when the client has not been fully engaged from the start.
As a best practice, senior stakeholders need to have an engagement plan with all users of the new system as well as involvement from key players and the outliers in all if not most of the requirement gathering sessions.
2. Set the scope.
The System Integrator and the Stakeholder must set the scope prior to the project being kicked off.
This would involve the business analyst (BA) meeting with the key stakeholders and capturing the “As-Is” business processes and the “To-Be” process. This does not have to be an exhaustive list but the process for Phase 1.
The Business Analyst should also capture the high-level EPICS for the user stories to be in the first release of the initial scope. Again, this does not have to be an exhaustive list
Select a champion (or two) who will be the go-to person for any issues and queries.
3. Select the right tools
The business and the BA will agree on the right tools to use during the first phase. They need to use online collaborative tools like JIRA (other tools are available), alongside an online process mapping tool such as Elements Cloud or Lucid Charts.
In my experience, try to avoid using too many spreadsheets as they become cumbersome and difficult to maintain. Finally, end-users must be trained in the use of these aforementioned tools.
The business analyst and the ‘champion’ next have a kick-off meeting to capture the Efficient, Programmable and Interchangeable Code System (EPICS). After the initial meeting workshops will be set up in a timely manner.
After every workshop action items are captured and addressed in each subsequent meeting. Whiteboards are favorable for user stories, or if remote working a shared collaborative document that all participants can access.
5. User Stories
Its the responsibility of the BA or a stakeholder (to facilitate engagement from the business) to capture each user story (which are simple descriptions of a feature) using the following template:
As a < type of user >, I want < some goal > so that < some reason >
A user story should have acceptance criteria, which have to be testable and limited to three items and capture any Non Functional Requirements (NFRs).
User stories can be linked to an EPIC that will hold one or more user stories. and recorded on post-it notes, white-board or shared document. Each user story has to be numbered or have an ID (e.g Req-001) and used as discussion points.
6. Product Backlog
User stories need to be prioritized using a simple numbering system (1-10 for example), which becomes the product backlog.
7. Agile Delivery using Sprints
The BA will walk through the user story to all participants (developers and testers,) who are going to be building and testing the application It will be prudent for the team to score the complexity of the story by using a story-pointing exercise. Story pointing defines how complex a story is for each participant and an average is taken (more diverse points on a story can be discussed until a quorum is reached).
It is then the responsibility of the BA with the Project Manager (PM) to define the number of sprints for delivery. The sprints are to have a specific start and end date and can last up to 3 weeks. All items higher up in the backlog must be put into an earlier sprint for delivery.
The BA is responsible for answering any questions from the Dev or the Test Team, during the sprint cycle. Daily meetings should be held at the same time to discuss progress and what the team did yesterday and what they are going to do today. It should not be a meeting to discuss technical issues that should be addressed outside of the daily scrum. A scrum master if one is available should remove blockers for the team to do their job. Do not forget, the NFRs should also be addressed during a sprint.
8. Test Test Test
The test team needs to write test scripts for each requirement and they have to link the scripts to each requirement. Scripts should be linked to the requirement using the requirement ID or requirement number.
The test team must write both positive and negative scripts.
- Defects should have steps documented, any screen-shots provided and a recording should be made if possible of the defect
- The test team, the stakeholder, and BA will be responsible for testing the requirements in each sandbox.
- The test team, the stakeholder, and the BA should also test production environments before the build is made live.
- The BA is responsible for the warranty period for up to 4 weeks.
9. Show and Tell
At the end of each sprint, the BA should show the feature to the stakeholders. All feedback, defects, enhancements must be logged for a future build.
By following these tips you can ensure that Salesforce or any other technology can be successfully implemented into an organization. By following these steps you will see the timescales of the project drop dramatically while helping to cover all of the requirements set out by key project stakeholders. In the end, the most key thing is that constant communication occurs across all of those involved.
Sanjay Sood – Salesforce Test Manager, Salesforce Agile Business Analyst and Blockchain BA Analyst