Snapshot can now create Sprints and User Stories that help Salesforce administrators manage complex Orgs with collaborative projects and teamwork automation. Project managers can create Sprints and assign User Stories to individual developers and administrators. These individual contributors can add metadata assets and deployment tasks to their User Stories. Lastly, a release manager can deploy the User Stories into any destination Salesforce Org, developer project, or online repository. Let’s take a quick look at what you can do with Sprints and User Stories!
The Manage Sprints interface is where project managers can create, edit, and delete Sprints and assign User Stories to individual contributors. Sprints can be managed with a simple to do list, a Kanban Chart, or a Gantt Chart. A simple Sprint might be managed with a to do list. A more complex Sprint might be managed with a Kanban Board. A long running Sprint might need to be managed like a project with Gantt Charts. You can use all of these visualizations at the same time or focus on one in particular. Here is the first tab of the Manage Sprints interface.
You can turn on awesome teamwork automation features for any Sprint and send email notifications when a Sprint is created, deleted, deployed, or assigned a new owner. You can also notify individual contributors when a User Story is created, deleted, assigned, or when the Kanban Stage changes. Sprints make collaborative Org Management a breeze!
You can view your Sprints with a Kanban Board in both Snapshot and Salesforce Lightning. The Kanban Stages are shown across the top of the board with team members displayed down the left-hand side. Kanban Boards help manage work by showing which team members are available and the current stage of all the Stories. User Stories can be reassigned to different Stages or team members by dragging and dropping the cards on the board.
Every Sprint also has an optional Gantt Chart interface. Each User Story is displayed as a task bar on the chart. Gantt Charts are useful for long running projects where some Stories must be completed before other Stories can begin. The Gantt Chart will calculate the amount of time for the entire project if some stories are delayed or contingencies change.
Keep track of Sprint progress with a Burndown Graph. This graph shows when a Sprint is behind or ahead of schedule.
The Update Story interface is for individual contributors that have been assigned User Stories by a project manager. The Story Owner can add metadata assets and manual deployment tasks to their User Story. This information is saved with the Story for collaborative use by other team members. The metadata assets attached to the User Story can be tested in context and saved.
When the User Story is finished, the Story Owner can make a pull request that moves the Story into deployment. The Sprint Owner is notified via email about the pull request.
Some deployment tasks will be part of any Sprint. For this reason, we have added the ability to create global task templates that can be reused. Each task contains the option to launch the source or destination Salesforce browser and to run a command line. The browser can be used to start a manual operation with the setup menu. The command line results will be included in the Sprint History when the task is completed.
All of the Sprint and User Story interfaces provide instant Overlap Awareness if other team members are using the same metadata assets that you are. Item on the Job List will appear in red if they are overlapped with other User Stories in the same Sprint. The tooltip for the field will show who else is using the object and the name of their User Story.
The final tab looks similar to the regular deployment interface. The Update Story button will save all of the selected deployment tasks and metadata assets into the current User Story. The Test Deployment button will conduct a validating deployment using the selected assets against the destination Org.
Deploy User Stories
The Deploy User Stories interface is designed for release managers who need to deploy a Sprint or User Story into an Org, a developer project, or an online repository. This interface could also be used by an individual contributor who wants to move a User Story into a Scratch Org or some other destination.
If the two developers are working on the same piece of metadata, then there is a conflict and the merge panel will be displayed. In the picture below we can see that one object has a description and the other does not. Since adding a description is nondestructive, the left hand Accept button is automatically highlighted indicating the best way to resolve the conflict. Every aspect of the merge process is guided by the user interface. This is way better than trying to resolve conflicts in a text editor!
At any point the release manager can select the Automatic Merge option and look at the conflict map. This shows all of the component parts of the metadata asset across the top of the screen and all of the conflicting User Stories down the left-hand side of the screen. The conflict map can be exported for review by the engineering team.
In some cases, a release manager might be tempted to send the conflicting User Stories back to the individual contributors and let them figure it out. The Notify Owners button will send an email to the Story Owners, along with an attachment that contains the conflicting asset data and the conflict map.
Some Sprints will not have any asset overlaps, and in other cases the Merge Conflicts interface must be used to resolve problems. When all of the selected User Stories have been merged into a single metadata source, then the release manager can compare the assets against the destination Org.
The next tab begins the deployment process for the merged User Stories. First, the before deployment tasks are completed and checked off one by one. In some cases, a deployment task might launch a browser to begin setup menu changes or to run a command line test. When all of the before deployment tasks are completed the release manager can proceed to the next tab and deploy the assets.
The Deploy Assets tab is very similar to the regular deployment interface. You can deploy User Stories into a destination Org, developer Project, or online repository. When you are finished, complete the deployment by completing the after tasks checklist on the last tab.
Every time you complete a User Story deployment the full history of what happened is added to the Sprint History object. This records the list of deployed User Stories, the before and after tasks that were successfully completed, and the results of the deployment.
There you have it! This Blog has covered some of the cool new features behind Sprints and User Stories. You will need the latest Managed Package for Snapshot version 3.5 to start using the new User Story capability. Let us know if you need help. If you want more information, please check out the User Story whitepaper below: