Feature teams often employ the concept of Planning Poker (or Scrum Poker) to help estimate the effort required to complete a given user story. Each team member is provided a set of cards, which are used to provide their estimate for the level of effort required for a given story. Most teams employ decks that utilize a Fibonacci-like sequence of the following values: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Experienced scrum masters make teams aware that an eight-point story should be able to be broken into a three-point and five-point story. As a result, stories are typically not worthwhile to estimate as anything greater than a value of eight.
It is helpful for feature teams to agree on a baseline story. That baseline story helps define what a given story value resembles. In my personal experience, a three-point effort is often used, since it falls in the middle of usable sequence range. The team can reference this baseline story, understand the effort required, and conclude that is the definition of the corresponding baseline value.
Over the years, I have referenced this gamified technique for story estimation in the Agile Zone at DZone. Two of my favorite articles are noted below:
Why Salesforce?
The use of physical card decks is not as effective in a world working through a pandemic which has transformed feature teams from being located in a dedicated team room to a 100% remote situation. While mobile applications can be utilized in place of physical cards, the idea of having a contained system to host the planning session and process the results seems more ideal.
Organizations that employ the Salesforce ecosystem have the necessary infrastructure to introduce applications that can be developed quickly and avoid having to handle aspects like infrastructure needs. Organizations which do not currently utilize Salesforce can get started at no cost using one of the free editions (like Salesforce Developer Edition) with minimal effort.
While a custom application could be created in Salesforce and utilize Lightning Components to provide a polished appearance, an application has already been created by Aditya Naag (@adityanaag) and is a fully opened-source packaged application for Salesforce.
I wanted to try something different for my team and utilize Aditya's application.
Why Heroku?
The challenge with using a Salesforce-based solution is that not all of the feature team members will have a Salesforce account. In fact, in the twelve years I have been utilizing Agile principles, there has been only one project where the entire team was self-contained to a single organization. Every other situation utilized external staff to handle aspects of the project which are not core to the corporate team. This is no different with my current team - having corporate team members who are located in North America and external consultants located in Asia and Europe.
These external consultants would also need a way to utilize the planning poker application, without the need to acquire a Salesforce client license. Given the ease by which Heroku can bring applications up to speed, using Heroku to provide a guest client seems quite logical.
Using Node.js as a backend service and Lightning Web Components Open Source, Aditya's repository includes a Guest Player application, which can be run from Heroku in a matter of steps. Of course, if all participants in the Planning Poker session have their own Salesforce license, the Guest Player application setup and configuration can be skipped.
The planning-poker-salesforce Repository
According to the README.md, the planning-poker-salesforce application is a consensus-based, gamified technique for estimating user stories in Scrum. This app allows you to utilize this technique for your planning and is completely built on Salesforce.
- Choose your own User Story Source Before starting a game, you can select any Salesforce object to be the source of the list of user stories, and save the consensus (Story points) directly to the user story records.
- Use pre-defined card sets or create your own This app comes with pre-defined card sets like Fibonacci and multiples of two. You can also create your own custom card sets.
- Hidden Cards All player's responses are hidden until the timer runs out or until the host chooses to reveal them.
- Host Controls The host has options to show a timer, hide or reveal cards, reset votes and more. The host can also play the game if they choose to.
The planning-poker-salesforce repository, along with some type of Salesforce Org and an optional free Heroku Dyno provides everything needed for a feature team to host a planning poker session. The architecture appears as shown below:
The remainder of this document will walk through setting up Salesforce and Heroku, then demonstrating the planning poker solution in action. For the purpose of maintaining confidentiality with my client, example data will be utilized for the remainder of this article.
Setup & Configuration
There are two options to introduce the planning-poker-salesforce application into Salesforce:
- using a package
- using SFDX commands
Both options are described in the following link:
https://github.com/adityanaag3/planning-poker-salesforce#installation
At this point, the planning-poker-salesforce application is ready for use in Salesforce for participants with a Salesforce license. Users with the "Planning Poker Player" permission set will be able to join the session created by a user with the "Planning Poker Host" permission set.
(Optional) The Guest Player Application
If there is a need for at least one player without a Salesforce license, a certificate needs to be created which will allow the same Salesforce org to communicate with the Node.js application that will be running in Heroku. Implementations where all users utilize a Salesforce account do not need to follow this step and can continue to the "Hosting a Planning Poker Event" section (below).
From my Mac Book Pro, I executed the following command in a new folder I created for this article:
openssl req -nodes -new -x509 -keyout private.pem -out server.cert
Below, is the output I received from executing this command:
Generating a 2048 bit RSA private key
..................................+++
..................................................................+++
writing new private key to 'private.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields, but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:US
State or Province Name (full name) []:IN
Locality Name (eg, city) []:Zionsville
Organization Name (eg, company) []:JVC
Organizational Unit Name (eg, section) []:Development
Common Name (eg, fully qualified host name) []:Planning Poker
Email Address []:<my-email-address-was-entered-here>
As a result of the command above, two files are created:
- server.cert - public key of the SSL certificate
- private.pem - private key (encoded and created in a Base-64 based PEM format which is not human-readable)
Within Salesforce a Connected App needs to be created from the **Setup | Apps | App Manager **screen. I decided to call the connected app "Planning Poker Client" (Planning_Poker_Client) and configured as shown below:
The "Use digital signatures" option was selected and the server.cert (created above) was selected as the digital certificate. The Callback URL was also provided once the "Enable OAuth Settings" was activated.
The Manage screen for the Planning Poker Client is shown below:
The only difference here was to change the value for the "Permitted Users" property. Clicking the "Edit Policies" button allowed the "Planning Poker Player" permission set to be utilized:
Navigating to the App Manager now shows three applications installed and ready in Salesforce:
Finally, the Node.js application for non-Salesforce users needs to be created. The process can be started by using the following link:
https://heroku.com/deploy?template=https://github.com/adityanaag3/planning-poker-heroku/master
Once logged into Heroku, the following properties are set within the newly created Heroku Dyno:
The PRIVATE_KEY properties are the contents of the private.pem file created above. The SF_LOGIN_URL and SF_NAMESPACE have multiple values, which are defined in the following URL:
https://github.com/adityanaag3/planning-poker-salesforce#player-app-for-guests
Finally, the SF_USERNAME is the unique username in Salesforce which was used to create the application. This can also be any user which maintains the Planning Poker Player permission set.
With the Heroku Dyno up and running, everything is set to start a planning poker session:
Hosting a Planning Poker Event
Within Salesforce, I created a very simple backlog item for estimation by the planning-poker-salesforce application:
Keep in mind, use of another object in Salesforce is also possible, which is linked in the Game object creation step (below).
Next, I created a game called "Planning Session 1".
Aside from providing a name for the entry, I specified that the host could vote during the planning poker session. I also set all of the attributes for the Game Data Sources. This is something I really appreciated about Aditya Naag's design - to be able to utilize different sources for the data used by the planning-poker-salesforce application. One example would be the seamless integration with Agile Accelerator.
With a planning poker game created, the next step was to navigate to the Host Planning Poker app in Salesforce and select the Host Planning Poker tab.
Once there, the "Planning Session 1" option is selected and the "Launch Game" button is clicked. At this point, other users can join the planning poker session. Guest users simply need to launch the URL for the Heroku Dyno, which will present the following screen:
The game key is displayed in the screenshot below, which also provides a summary of all of the players who have joined the session:
Playing Planning Poker
Upon single-clicking the "Start Playing button", the first (and only) backlog item is presented:
Each guest user can vote confidentially. Two sessions are displayed below:
Once all of the votes have been cast, the host screen appears as shown below:
At this point, the team discusses their estimates. Once a consensus is reached, the Host Controls are updated as shown below:
In this example, a score of 2 was selected and the "Save Consensus" button was clicked. The save action automatically updated the source record - include objects external to this application (like Agile Accelerator). However, if another vote was required, the Vote Controls can be used to clear out the prior results.
The "Next Story" button can be used to repeat the process for the remaining backlog items. When finished, the host simply needs to utilize the "End Game" button.
Conclusion
In the nearly thirty years I have served in a technologist role, I truly respect the cost of employing technology to meet the needs of an organization. Along this journey, the one key point that I try to instill in future generations is to avoid doing things which do not drive innovation and progress for the underlying business needs of the corporation.
Salesforce provides functionality that can be configured and customized to fit the needs of an organization - saving significant costs when compared to building, managing, and supporting a custom CRM application. Heroku provides similar value to allow feature developers to focus on meeting the needs of the business and not have to gain an understanding of a complex cloud option. Aditya Naag's planning-poker-salesforce provides an open-source option for feature teams who need a robust solution for story effort estimation. These three aspects lead to a rare situation where a need is being fully met without a single line of original source code. My current team has really enjoyed using this approach with our Planning Poker sessions.
In the end, an example has been introduced that helps keep the cost to support the feature team minimal and allows the team members to remain focused on making business-driven improvements. In my book, that is the key factor toward facilitating success.
(published with the kind permission of my colleague John Vester)
Latest comments (0)