Skip to content

CRM Guide - Discovery - Scope

1. Understand your audiences / users

 You need to understand who will be using the system before you start gathering your requirements. If you do this well, you could use AI to help you on the next stage.

We've provided an easy template for you to use (note these are different from user personas that you might create for a new website - they have a different focus). 

2.  Build out user stories to document your requirements

What is a user story

  • User stories are a way to describe your requirements without needing technical expertise

  • Acceptance criteria against a user story allows you to define what success looks like

  • User stories follow a set format - As a [user persona] I want to be able to [do something] so that [what you want to achieve]

Example user story

 As a fundraising manager, I want to be able to segment donors by giving history, frequency, and channel, so that I can target appeals more effectively. 

Acceptance criteria

  • User can filter donors by gift amount using a range or a specific amount, frequency, last gift date, and channel

  • Segments can be saved and reused for future campaigns

  • Segment count updates live as filters are applied

Why bother with user stories

  • They are specific and they stop you creating inarticulate requirements

  • People can create them without having any knowledge of how systems work - they simply describe what they want to be able to do

  • They stop you designing the system (which usually isn’t your job)

  • They will help system providers better understand what you are trying to achieve

  • They will help reduce the implementation time if done well

  • They make you think about the 'why' of what you are asking for

  • They help you prioritise needs

  • Building proper acceptance criteria supports your testing plan, which will save you time later.

 We've provided you with some standard user stories to get you started. 

 How do I actually gather user stories? 

 We would recommend running workshops with team members and guiding them through the process by asking three key questions:

  • What's working really well now that you don't want to lose?
  • Focus less on the technology here and more on what the technology provides. For example, if fundraisers have a pipeline spreadsheet that works well for providing an overview, then the key takeaway is having a pipeline with specific data points, not that it is in Excel.
  • What's hard/challenging/taking up loads of time?
  • What are you wishing for?

From here, you can start to expand each of the points raised and express it as a user story.

If you have created detailed user personas, you could use AI to suggest some standard user stories with acceptance criteria to get you started. This won't be everything you need, there may be stories you don't need, and they will need reviewing carefully to make sure they match your organisation, but it could still save a lot of time and give you a strong steer to build them out further. 

3.  Create a requirements matrix and prioritise 

 You’re unlikely to get everything you want. You are likely to have to make some compromises. The easiest way to do this is to apply a prioritisation score to each user story. Prioritising your requirements will help the provider to understand if they are a fit and will help you decide whether this system is the right one for you.Use the MoSCoW matrix to prioritise your requirements:

https://community.atlassian.com/forums/App-Central-articles/Understanding-the-MoSCoW-prioritization-How-to-implement-it-into/ba-p/2463999

  • (M) Must have: These are critical requirements that the project needs in order to be completed. If these are not fulfilled, the project is considered a failure.
  • (S) Should have: These are important but not critical features of a project. They are high priority items that are not as time sensitive as the must-haves.
  • (C) Could have: These are desirable features that do not affect the project's overall success. They can therefore be included if time and resources permit.
  • (W) Won’t have: These features are the lowest priority, or are not necessary for the current delivery cycle. They are agreed upon and recognised, but are dropped for the project’s current timeline.

5. Build a brief

 To ensure providers are really clear on what you're looking for, we recommend building a brief to send to them along with your requirements. This allows them to understand who you are, what you want to achieve and the parameters within which you operate. 

 We have provided a template to help you.