But that's not the full story; Mercury has lots of standard features in place. We don't want to waste time discussing and describing functionality that is obvious and only needs configuration.
Leveraging standard Mercury
We want to make sure that we leverage standard Mercury and make the most of our efforts (in time and money) to build the features that make your e-commerce solution stand out from the competition. Time-to-market needs to be as short as possible and customizations need to count. How do we accomplish this?
Startup & analysis phase
To start the Mercury implementation process, we begin with an analysis phase in which we focus on understanding the total scope of the project. We therefore need to determine the customer’s requirements for the e-commerce solution. As there are a lot of choices to be discussed, we have set up four workshop tracks in which we handle all important topics.
The goal of this analysis phase is to reach a complete backlog of user stories and tasks that need to be accomplished in this project. This backlog can then be estimated and planned. At the end of the analysis phase there should be a comprehensive project plan and budget. In the analysis phase, we focus on the following tracks:
- Application architecture and infrastructure
- Sitecore optimization
As part of the e-commerce track, we compare the features in Mercury against the specific requirements of the customer in a fit/gap analysis. To facilitate this analysis, we created several support tools.
First, we supply a demo online store that is a showcase of the standard features of Mercury. This demo online store will be prepared with a subset of the customer’s catalog and be slightly tailored to show the customer’s branding (colors and fonts).
Second, we plan and host several workshops that each target an e-commerce area: product, checkout, cart, self-service, etcetera. In these workshops, we use the demo online store to show the standard features in detail and discuss the specific requirements of the customer. Typical business users/roles we expect to participate in these workshops are the E-commerce manager, marketing and SEO specialists and the product owner.
The visual design of the online store is extremely important in supporting the customer's business goals. We therefore plan and host several workshops in the analysis phase to discuss brand identity, (conversion) goals, target groups and campaign elements. Which customer journeys can be defined? What are the key pages in the new online store? What is your competition doing? Typical business users/roles to participate in these workshops are the E-commerce manager(s), marketing specialists and the product owner.
As we don’t want to lose valuable time-to-market, the Mercury team will provide wireframes that support all standard features of Mercury. These wireframes will be modified in the next phase of the project to incorporate the customer specific
end-user features and serve as the base for the visual design.
Application architecture and infrastructure
As Mercury is an extension to the Sitecore Commerce platform, an important part of the project will be implementing
the Sitecore platform in the customer’s e-commerce application landscape. This triggers a lot of questions. Which back-office integration-interfaces are needed? Are there third-party services required? Will a CDN be used? How will the deployment and test cycle be implemented? Which environments are needed? How and where will this be hosted?
During the analysis phase, we plan meetings on these topics. The goal is to start building the infrastructure immediately when the analysis phase has been finalized and to kick off the development team.
The combination of Sitecore Commerce and Mercury empowers the E-commerce manager and marketer to provide an excellent shopping experience to each visitor. As the development team will be customizing the solution during the project to fit to the customer’s needs and is delivering new features, the E-commerce and Marketing departments can start working on their implementation plan. This will mostly be about standard Sitecore and Mercury functionality: which goals can be achieved in the online store? Which personalization rules will apply? Which engagement plans need to be in place?
We kick off this part of the project with a workshop on these issues. During the project, we have regular meetings to discuss personalization plans.
Our goal is to have a complete backlog at the end of the analysis phase. This will encompass all user stories that need configuration as well as those that need development. These stories will be described on a general level. Detailing will be done during the project. All tasks needed to set up the infrastructure and integrate and deploy it with other systems, deployments, etcetera will be also in the backlog. Furthermore, all tasks to support the project, such as Scrum events, project management and detailing on the user stories are in the backlog as well.
We now have an overview of all activities required. Within 1 week, we will give a general estimate on all stories and tasks, resulting in an overall budget in man-days that can be used to provide a first project plan. This will serve as the (first) baseline for the project. This baseline needs to be validated during the project and possibly adjusted to fit changing circumstances if needed.
In this phase, the Sitecore/Mercury environment is configured to support the customer’s situation. In this phase, we configure all user stories that do not need customization.
In the realization phase, the team will be working in sprints to deliver integrations, customizations, and new features. By working in three-week sprints, we get the important stakeholders involved in customer organization and receive feedback at a regular pace. In this phase, the project is truly agile: the product owner specifies functionality and sets priorities.
During this phase, the product owner and business consultant are a sprint ahead in detailing and approving the specifications of user stories. This way, developers can kick-start each sprint. The goal is to deliver a demo-able solution after each sprint with code that has been tested and accepted.
The number of sprints needed in this phase depends on several factors including but not limited to the complexity of functionality, technical complexity and team size.
The last sprint before the launch of the new online store is dedicated to making the system production-ready. Before we arrive at this phase we need to make sure the product environment is tested for performance. In this phase, final activities will be completed: final deployments, final catalog, redirects and possibly migrations.