Building and Testing Your Initial Release

In this chapter, we will cover how to build and test your Salesforce solution for initial release. We will go through what your solution consists of under the hood, the available Salesforce development models, and sandboxes. Then we’ll describe the agile team roles, the value of agile ceremonies, and how to effectively manage your development process. We’ll cover the governance mechanisms you can, and should, consider putting in place to steer your Salesforce project and the changes that may occur along the way. We’ll describe the various types of development phase testing you should be familiar with. Finally, we’ll go through the steps to create your data migration plan.

You will learn about the Salesforce development life cycle and how to organize an agile team consisting of both internal and external members, how to facilitate agile ceremonies, and how to govern the delivery of your Salesforce project. You...

Understanding the roles and responsibilities of your team members

It is the people in your team that will make or break your Salesforce project. Ensure you invest in making sure roles and responsibilities are clear, processes are optimized to deliver value as effectively as possible, and that you have a learning and growth mindset to continuously improve your setup.

In the previous chapter, business analysts and architects interacted with your business and technical stakeholders to break down the overall scope of your Salesforce project into user stories and create the solution design artifacts.

In this chapter, we’ll cover a hybrid agile delivery methodology, and as we are in the development phase, we’ll go deeper into its agile aspects.

You will begin configuring and developing your Salesforce solution. Depending on your chosen delivery methodology, some project members may not yet have been onboarded – but they are about to be.

Let’s start...

Planning your build phase

In a pure agile delivery methodology, the team plans their work continuously – either in sprint planning (Scrum) or by simply starting new work when new user stories meet the definition of ready and there is the capacity for it to be picked up (Kanban).

However, having chosen a form of hybrid agile delivery methodology, you’ll likely want to have some indication of the estimated duration of the build phase – both for budgeting and roll-out planning purposes.

In this section, we’ll discuss the advantages and disadvantages of various methods of estimating development effort and how you can plan development.

Let’s look at two methods of estimating effort:

• Estimating development effort in time format:
  • In the previous chapter, you broke down the overall scope into user stories and provided solutions for each of them. If you didn’t, go back and review this process.
  • To know the total number of estimated development...

Setting up your development model and environments

The development model and environments are part of your deployment model. Deployment means moving the technical components of your solution from one environment to another and eventually to production. You use different environments – sandboxes – to perform different types of testing in your development life cycle. The purpose of this is to make sure your solution works end to end as intended when it reaches production.

Let’s begin by looking under the hood of Salesforce.

Understanding the components of your Salesforce solution

The products Salesforce offers, such as Sales Cloud and Service Cloud, are cloud-based software-as-a-service (SaaS) products. That means your Salesforce org – depending on the licenses you have bought – comes with standard objects and standard fields out of the box (OOTB).

Salesforce is also a platform as a service (PaaS), which means you can extend, enhance, configure...

Establishing your development process

One of the key components of the development process is the sprint. A sprint is a term used in Scrum to describe a predefined duration in which the aim is to develop working software. We have already mentioned that a sprint’s duration is not set in stone – it can be decided that it will last anywhere from 1-4 weeks. Let’s look at what you should consider when determining your sprint duration:

• Will user stories need refinement during the sprints?
  • If yes, this will take time away from development. Having a short (1-2 weeks) sprint duration will impact the expected sprint efficiency beyond what is sensible, as the overhead for refinement and agile ceremonies is greater than the available time for development. If you need continuous backlog refinement sessions, increase your sprint duration.
  • If no, meaning you have already refined and provided solutions to your user stories upfront, then you may opt for a shorter sprint duration...

Governing your Salesforce project in the development phase

There are many things happening in the development phase of your Salesforce project, and it can be overwhelming to comprehend it all and get an overview. Your responsibility in the building and testing of your initial release is simple:

To create an environment, a structure, and processes to maximize the high-quality value output of your development team.

At a high level, you want to ensure your agile development team is:

• Building the right thing: This means ensuring your Salesforce solution will:
  • Be well received and used by the end users
  • Meet your objectives and financial targets set out in your business case
• Efficient: This involves making sure your agile development team is building your solution in the most efficient manner possible:
  • Value: Output x quality
  • Cost-efficient

In the following sections, we’ll break down what this means in practice.

Salesforce project governance

There are effectively...

Preparing your data migration plan

As part of your effort and analysis in the pre-development phase (covered in Chapter 2, Defining the Nature of Your Salesforce Project) you identified the systems that are currently used to support your business capabilities. As you are developing a new solution based on the Salesforce platform, your task now is to identify what data from your legacy systems needs to be moved to Salesforce and how to migrate it.

Your data migration strategy should answer the following key questions:

• What systems will you be migrating data from?
• What data will you be moving?
• How will you extract the data from the legacy systems?
• Which Salesforce objects does your data map to – where will the data reside?
• How will you transform your data to make it consumable by Salesforce?
• How will you load the data into Salesforce?

Start by listing all your legacy systems and data (objects) and note the number of records in each object...

Summary

You have completed a lot of activities to progress from solution design to building and testing the user stories of your Salesforce solution. You have also created a plan to migrate data from your legacy system(s) into Salesforce as you roll out your Salesforce solution to users. Having completed these activities, you should evaluate the state of your Salesforce project as you are nearing the end of Part 2, The Development Phase.

In the next chapter, we’ll discuss typical issues you may encounter in the development phase of your Salesforce project and how to mitigate and overcome them. You’ll also be provided with a checklist to evaluate the state of your Salesforce project.