Projects can struggle for a variety of reasons, one of which is poor requirements. You can overcome many obstacles such as poor planning or poor system performance, but poor requirements is not an option. While everything cannot be addressed in this short blog, what follows is a brief set of guidelines to ensure you capture requirements right thereby setting yourself up for a successful Guidewire InsuranceSuite Implementation.

The end objective of the requirements process is to uncover the real needs of the business and to document those needs in a clear, concise manner so that all stakeholders have a common and shared understanding of what the requirements are. It’s critical that you get off on the right foot.

  1. Set your foundation – In the Inception Phase of our implementation, we use the out-of-the-box User Stories as a starting point. What’s key here is the User Story description. Make sure this description for each Story is accurate and represents the actual intent of the Story. This is critical to ensure you demo the right features and functionalities in Inception and elicit high level assumptions.

  2. The User Story description is also essential to correctly defining the scope of a User Story. Stakeholders may identify additional features, functions or gaps that do not fall within the scope of a given Story. These may either be covered in another User Story or they may need to be captured and estimated as a Gap Story.

  3. Also make sure there are no User Stories missing. If there are, create them and schedule them appropriately in the inception sprint plan.

  4. Getting the User Story scope right, demoing the feature(s), eliciting high level assumptions in Inception, will form the basis for detailed requirements elicitation.

  5. The Inception Sprint Plan is also a good time to be thinking about your ultimate Conceptual Sprint Plan. At the end of Inception, you’ll need to come up with a Conceptional Sprint plan. In general most projects do not get enough time at the end of Inception to really come up with a detailed and thoughtful Conceptual Sprint plan, because it’s supposed to only be a “Conceptual” plan.  It’s not supposed to be the “Final” Sprint Plan. However, what can typically happen is that Conceptual Sprint plan will get etched in stone and become “THE” Sprint plan.  So better to be thinking about it early and throughout the Inception phase.

  6. Typically for Policy the Sprint Plan should follow the Policy Lifecycle, for Claims – the Claims lifecycle, and for Billing – the Billing Lifecycle. The best time to do your estimating is during the Inception Sprints clearly noting the basis of your estimate, based on the high-level assumptions against the Out-of-the Box assumptions for each User Story.

  7. Also consider logically grouping certain User Stories that go together or are dependent on one another. e.g. Policy Notes with Account Notes, Policy Documents with Account Documents, etc.

  8. Finally, don’t forget to address User Stories to address Organizations, Groups, Users, Roles and permissions sooner rather than later. Roles and Permissions for example will potentially affect other User Stories. Better to have defined roles and permissions as much as possible in early sprints so re-work is avoided in later spriints.

Once Inception has been completed and the Sprint Plan is in place get ready for detailed requirements

  1. Create your Sprint Agenda at the beginning of each Sprint. Make sure you have the right stakeholders on the invite. Be thoughtful, more isn’t always better. The key is the “right” people. Some stakeholders may be critical for a given User Story but not for other Stories.

  2. Define and agree on a requirement review and approval process.

  3. While you’re at it, define your Change process . . . you’ll need it. Agile is about being able to adapt to change and requirements WILL change. If they didn’t, we’d all still be doing waterfall.

  4. Generally, requirements elicitation is done in Requirement’s workshops with key stakeholders including the Product Owner. There are of course other methods which can be appropriate to elicit requirements such as document analysis, interface analysis, focus groups, brainstorming, proto-typing, etc. Use the appropriate method(s).

  5. In the detailed requirement’s phase, the baseline for each User Story is what you captured in Inception.  Start your requirements elicitation by re-reading the User Story Description to your stakeholders and consider the scope in terms of story points allocated to the user story.

  6. Based on the Description set the Scope for the User Story

  7. Re-demo the features/functionalities that make up the User Story

  8. Validate the high-level assumptions that were made in Inception for the Story (the 25,000-foot level) are still in fact valid.

  9. Encourage stakeholders to stay Out-of-the-box. That’s the power of a package application like Guidewire.

  10. Delve into the granular details of the requirements (the 5,000-foot level) and document in such a way that there is a common and shared understanding of what the requirements are.

  11. Consider the best way to model the requirements for a given User Story to ensure your requirements are complete for that Story: screen mock-ups, business rules, use cases, data flow diagrams. etc.  For example on a  Renewal Timeline Story, you’re going to want a detailed process flow of the Renewal timeline calling out what happens and when.

  12. Finally be consistent with your documentation. Consistency is one of the characteristics of a good requirement. It can be a challenge when you have several analysts capturing requirements. So put some governance around how your requirements will be documented and set the expectation with the entire team.

It’s very easy to do a poor job eliciting and documenting requirements, especially on complex mission critical insurance transformations. Regretfully on too many projects this becomes evident too late. Good, consistent requirements are an absolute must to successful delivery. The steps provided above while by no means exhaustive, will definitely help set you on the path to eliciting requirements that will help your transformation succeed.

If you have comments or questions about this blog, please feel free to contact Matt Nicholas – Cynosure PolicyCenter Business and Requirements  Lead at and we will be happy to assist you.

+ posts
1 Star2 Stars3 Stars4 Stars5 Stars (1 votes, average: 5.00 out of 5)


Posted by Matt Nicholas

Leave a reply

Your email address will not be published. Required fields are marked *