Product Backlog Preparation: Astro360 Salesforce Case Study

Following from our article on the Project Documentation needed for the Astro360 project, this is the third article in the Astro360 Salesforce Case Study, a fictional account of how AstroLift used Salesforce to manage their customer relationships in the most cost-effective way by putting them at the centre of everything they did.

The Product Backlog is a list of work items that represent what needs to be built to deliver the product or solution that the project was set up to deliver. The Product Backlog is owned by the Product Owner, and can be built by any number of project team members, from a number of exercises and artefacts, such as:

In projects run in a purely agile way, the backlog is developed as sprints progress and work is ‘Done’. However, since Nel is on a budget and needs to have an idea of how much it will cost to engage all the different project teams (including external partners), his hybrid agile approach calls for the product backlog to be established up front. This backlog will contain high level user stories which will form the basis of an order of magnitude estimate of effort (number of hours required) and duration (start and end dates of each phase of the project).

Product Backlog sticky notes
Workshopping with sticky notes can be a great way to visualise priorities for Product Backlog items

Requirements Gathering

Before we can start to think about what to build, we need to discover what the system needs to be able to do. Requirements gathering is a vital part of this discovery phase, and can consist of:

  • Interviews
  • Questionnaires
  • User Observation
  • Workshops
  • Brainstorming
  • Role Playing
  • Use Cases and Scenarios
  • Prototyping

and can be conducted with the Product Owner, Subject Matter Experts, End Users, and/or Business Analysts. These workshops can be used to investigate the current processes and systems used to achieve the outcomes we’re looking to improve, explore how these stakeholders see the future state solution working for them, or take them through what features are possible for the future state that they might not be aware of.

During the Discovery phase Klaus wants to be relatively high level with the depth he goes into on each Product Backlog item. He just wants to get an idea of what needs to be done to deliver on the requirements of the project so that he can help Ernie design the future state architecture, and Frankie estimate timelines, resources and budget.

As Klaus gathers his requirements, he starts to write out the user stories in the following format:

  • As a (persona type)
  • I can (use the system in a specific way)
  • So that (I can achieve a specific goal)

Personas

Because persona types are an important part of user stories and process maps, Klaus needs to build out a persona map for each of the personas that will interact with the system. Even though not all personas mapped here will interact with the system from the first release, he knows that it’s vital to have an overview of each set users in the target state:

salesforce product backlog persona internal sales agent
Internal Sales Agent
salesforce product backlog persona internal sales manager
Internal Sales Manager
salesforce product backlog persona internal service agent
Internal Service Agent
salesforce product backlog persona internal service manager
Internal Service Manager
salesforce product backlog persona executive director
Executive Director
salesforce product backlog persona system administrator
System Administrator
salesforce product backlog persona customer
Customer

Process Maps

So that Klaus understands what the current process is, and what the Product Owner wants the future process to be, he needs to create high level as-is and to-be process maps to represent these processes. These process maps will help him create his user stories, and will help Ernie with his Solution Architecture document.

The following processes have been identified as important to the project:

Sales Process – Business Customer – BP-#1
Sales Process – Residential Customer – BP-#2
Support Process – BP#3

The Backlog

Now that Klaus has his personas and high level processes, he has enough context to capture the user stories that will define what functionality will be available in Salesforce. Klaus decides to group his user stories by Epic:

Sales Agent Epic
  • As a Sales Agent, I can keep track of all sales and service related communications with a prospect or customer, so that I have context around the customer’s relationship with AstroLink
  • As a Sales Agent, I can provide the customer with accurate quotes, so I can sell the customer the product that best serves their needs
  • As a Sales Agent, I can get provide the prospect or customer with discounts, so that I can give high-value clients better deals
  • As a Sales Agent, I can access new leads generated from the website, so that I have the information to effectively make my sales calls
  • As a Sales Agent, I can call a customer or prospect though the system, so that I can make calls easily from the user interface
Sales Manager Epic
  • As a Sales Manager, I can keep track of all sales and service related communications and subscription history with a prospect or customer, so that I can support my team members’ activities
  • As a Sales Manager, I can approve or reject discounts Sales Agent request on deals for prospects or customers, so that my team strikes a balance between profitability and sales volume
  • As a Sales Manager, I can create reports and dashboards in the system, so that I can keep track of how my Sales Team is doing in real-time
  • As a Sales Manager, I can reassign deals between team members, so that when a team member is away, the deal can be closed
Service Agent Epic
  • As a Sales Manager, I can keep track of all sales and service related communications and subscription history with a prospect or customer, so that I have context around the customer’s relationship with AstroLink
  • As a Service Agent, I can have Service Requests routed to me based on my skills and availability, so that I have a manageable workload
  • As a Service Agent, I can receive Service Requests from email, web chat, phone call, or SMS channels, so that I can help customers within their preferred channel
  • As a Service Agent, I can escalate Service Requests to a Service Manager if I can’t resolve it within the relevant SLA, so that the customer receives the appropriate service in a timely manner
  • As a Service Agent, I can send post-resolution customer satisfaction survey to the customer, so that I can get feedback on the service I’ve provided
Service Manager Epic
  • As a Service Manager, I can keep track of all sales and service related communications and subscription history with a prospect or customer, so that I can support my team members’ activities
  • As a Service Manager, I can have cases escalated to me by my team members, so that I can provide Tier 2 support when necessary
  • As a Sales Manager, I can create reports and dashboards in the system, so that I can keep track of how my Service Team is doing in real-time
  • As a Sales Manager, I can reassign support cases between team members, so that when a team member is away, the case can be resolved
  • As a Service Agent, I can send post-resolution customer satisfaction survey to the customer, so that I can get feedback on the service I’ve provided
Executive Director Epic
  • As an Executive Director, I can view monthly sales and service metrics in the system, so that I am informed of how the teams are doing
System Administrator Epic
  • As a System Administrator, I can utilise a continuous integration / continuous deployment process, so that I can effectively manage business-as-usual changes after go-live
  • As a System Administrator, I can have full permissions to make changes to the system, so that I can support business-as-usual changes
  • As a System Administrator, I can access a knowledge base of documentation on the functional and technical aspects of the system, so that I know how the system works and how to change it
  • As a System Administrator, I can edit the Integration Platform, so that I can maintain the integration layer for the solution

In the next post we’ll see what Ernie came up with before his High Level Design presentation with Nel, Jill, and the wider project team.

Leave a Reply