From Siebel to SAP CRM with Scrum

In my project we are rolling out SAP CRM On Premise for sales, service and marketing to all global regions for an international consumer products company. 
For one of the regions we are replacing the current Siebel application, that is in use by about 700 users to support sales and service processes, by SAP CRM. This blogs provides project experience on how to accomplish such a migration project from Siebel to SAP CRM in a short time frame with a scrum way of working.

We started the project by requesting the Product Owner (PO) and Subject Matter Experts (SME) to demo how the sales and service processes were supported in the Siebel system to have a good understanding of the business processes that needed to be migrated from Siebel to SAP. In these demo sessions it is important to focus on the business processes to support and not on the technical details on how the solution was or needs to be implemented. 
Once we understood the business processes we had to support in SAP CRM we could define the epics of the project. An epic is a large body of work that logically belongs together. We used JIRA as administrative tool to document the epics and later the stories.

 

We defined ‘basis’ epics like Account Management, Product Management, User Management and Email Integration. These basis epics were needed to support the ‘business process’ epics like Contact Center Sales, E-commerce, Employee sales and Repair Processing. Once the epics were defined we aligned with the PO which epics would bring the highest business value so we could start working on these epics first. 

At the same time, it is also important to identify the high-risk epics, e.g. epics with dependencies on other scrum team or other projects or that have long lead times, so we could also start working on these epics early in the project and mitigate the risk. Examples are epics for data migration or with complex interfacing.

It proved to be essential to have a PO who is willing to change the current way of working and a scrum team that is willing to listen and understand the business and get the most out of the standard system.

For each epic, we defined first ‘place holder’ stories to have an overview of the high-level functionality to be built. We prioritized these place holder stories focussing on the priority epics. Each scrum team had a business process analyst (BPA) who together with the PO refined the stories upfront. These prepared stories were moved from the backlog into the 'Wishlist' sprint. Due to this preparation, the refinement sessions and story pointing with the complete scrum team didn’t take a lot of time as the stories were already prepared in the Wishlist. From the Wishlist we moved the stories in the actual sprint based on capacity and team velocity. 

 

For each story we indicated if it was a ‘roll-out’ story, meaning that the functionality was already existing in the system for other regions and only needed to be rolled-out to the new region, or if it was a ‘new functionality’ story. We decided only to work on these new functionality stories if it was needed for legal or compliance reasons. This helped to prioritize the backlog. 

 

For each epic we identified a first point of contact in the scrum team who was the first contact for questions in the team and from other teams and the business and who kept the complete overview of the solution and the progress of the build. 

We also learnt it was more important that the scrum team member who had to work on the story understood the details of the story and was confident to do the story pointing than that the complete team understood all the details and could do the story pointing. The responsible scrum team member liked the ownership and responsibility for a story.

 

To the stories that were not story pointed yet we assigned temporarily dummy story points not from the Fibonacci sequence so we could easily recognize them. Due to this all stories were (dummy) story pointed and we were already early in the project able to predict, with help of JIRA reports, the realistic go-live date and we could take appropriate actions. 

At the end of each two weeks sprint we organized a sprint review session to demo the delivered functionality to the PO, business representatives, testers, trainers, other teams working in the same system and project management. As agendas were fully booked we learnt it is important to schedule the session well in advance and to re-schedule if key stakeholders could not participate. 

 

To involve the end user as much as possible we organized a first User Acceptance Test (UAT) early in the project. Although not all functionality was delivered we made sure some end-to-end processes could already be tested and could provide us the valuable feedback of the end user in an early stage. We will organize a second UAT to test the remaining functionality. We used HP ALM to register the test scenarios and test results and the defects.

In total we will do 14 sprints of 2 weeks and are on track to meet the planned go live date. If you would like to know more about doing SAP CRM projects with scrum in an agile environment please reply to this blog or contact us at www.acorel.nl/contact.