In Right First Time we explore how assuring successful change management is crucial in transformational programmes. Dynamic software applications, including GuidewireTM InsuranceSuite, allow insurers to transact policies and enable digital platforms more effectively than ever before. However, implementation is not merely a matter of getting it done, but in getting it done right the first time, every time.
The Backlog is a catalogue of the work required to deliver a project. This work might be the installation of a new platform, the addition of new features, configuration of a system, bug fixes, changes to infrastructure, or other works needed to meet specific business requirements. In essence, the backlog is a big to do list, around which the project team organise their activities.
The building blocks of backlogs are most usually; Epics, Features and User Stories. These, with increasing granularity, define the work required. At the lowest level, User Stories precisely describe the functionality to be delivered, and the criteria the business expects for that functionality to be accepted as complete.
Under an Underwriting Epic, an example Feature might be the functionality to connect to an external rating engine, such as Radar, or Mendix. Under that Feature, the User Stories would define how the policy administration system connects to and retrieves data from the rating engine.
The ‘Product’ in Product Backlog is the insurance software under development. This defines the work required. For instance, during the implementation of a new insurance policy admin system, the Product Backlog lists all configurations, customisations and infrastructure required to make the platform ready to transact policies.
The overall Product Backlog may be subdivided, dependent upon the programme. For example, it is very usual to subdivide a Product Backlog into Releases, enabling a clear demarcation of what functionality is to be delivered and when.
Releases can be constituted in a number of ways, from Releases focusing on new technologies, such as digital quoting journeys, or by line of business, starting with Private Motor, with Commercial Fleet in a later Release.
Constant attention is required to maintain the Backlog and organise subdivisions, such as Releases and Sprint Backlogs. In Backlog Refinement, the Product Owner (the person with responsibility for the Product Backlog), with the assistance of others on the programme, will actively manage the Backlogs. The Product Owner ensures the Backlogs reflects the vision for programme and will realise the expected business benefits.
The Sprint Backlog is a further subdivision of the Product and/or Release Backlog, which is a discrete bundle of work a development team can complete within a Sprint. A Sprint is a timebox, usually lasting for four weeks, within which the team commit to delivering the Sprint Backlog, as agreed with the Product Owner.
Insurance transformational programmes tend to utilise multifunctional development teams, with a close alignment to Stakeholders, particularly from Underwriting and Claims, who will have a vested interest in what the teams will deliver within the Sprints.
How Solution Assurance helps
Solution Assurance is a vital third-party service that assists customers to install and develop effective enterprise insurance software solutions.
Effective Backlog creation and management are crucial to a successful programme. Solution Assurance Consultants are involved in all aspects of backlog management. During inception, Solution Assurance ensures the Features and User Stories are appropriately devised. Throughout the Build Phase, in Backlog Refinement, Solution Assurance supports the Backlog management and adherence with expected business outcomes. Within Sprints, Solution Assurance ensures a high-quality delivery of the works required to meet the Sprint goals. Solution Assurance may also engage with User Acceptance Testing to ensure that what is delivered, in a full-cycle analysis, fulfils the business benefits the programme Stakeholders expected.