The story of a Salesforce Sprint

Having rolled out Salesforce across multiple organizations — Leading Media & Entertainment, Financial Service, Manufacturing and Retail organizations one thing I can say is that there are no panacea and each situation requires it’s own approach.

So, lets start with an initial template on a typical sprint- outlining the various activities to help you plan your next Salesforce sprint more effectively

Before we get into the outline, these are some of the assumptions :-

1. All the user stories are detailed, estimated and planned with a low error (~20%) margin prior to the sprint beginning
2. The ideal team composition DEV : 8–10 , BA : 1–2, PO : 1, Scrum Master : 1, QA : 2, Automation : 1, Trainer : 1
3. The team is matured and has done a Mock Sprint (Sprint 0) to understand the nuances of Agile Collaboration, transparency and cross-functional capability
4. There are pre- and post- sprint activities (environment setup, etc) that are taken care of — usually by a external service team

Story of a typical Salesforce Sprint

Now let’s delve a bit deep into the benefits of this template :-

a) Accurate capacity planning : More often, Scrum masters over-estimate dev capacity, leading to the entire team working over weekends and burning out. With this approach, instead of filling up the dev capacity for the entire 4 weeks, we are cautious in estimating Sprint based on 3 weeks of functional capacity — since the last week the dev will be pulled into Deployment, Defect fixes and other fire-fighting activities

b)Include Testing : The most common misnomer is that Salesforce development does not require testing (due to mandatory code coverage prior to production release). But this does not cover process requirements and any custom developments

c) Training prep through the Sprint : Very often training / change mgmt is relegated after the Sprint is released, instead if it is integrated within the Sprint — the Trainers (Super Users) can understand nuances of the Salesforce platform thanks to interaction with Devs/QA/BA

d) Limited PO involvement : Product owners are very scare and costly resource. In this approach, we are going to leverage PO capacity only partially during each week to perform iterative UAT review.

e) Analysis and Planning are included within the Sprint : Very often, we have BAs outside the sprint for performing Analysis or Sprint planning. This reduces the Team velocity since the Devs and other critical resources are not engaged appropriately. Having them included in teh Sprint leads to massive velocity increase.

Some options for modifying the template :-

1. Cross-functional capability : Based on individual capability, we can definitely shrink the team size by having the QA also take over regression testing, the BA take over PO/ Training roles/ QA roles, the Dev take over BA/Training roles
2. Regression : While often underrated, Regression can be pushed after the Sprint is delivered — as long as they are not being ignored

I hope this template was helpful for you to plan for your Sprint.

What challenges did you face while running your Salesforce scrum ?

Do you have any further Tips ?

Reach out to me at deep.bhaskaran@gmail.com