Aim of the Page: The page is to support TIS team with BA analytical skills and provide framework to carry on good work
Page contents
- Agile BA role around:
- Story Research
- User Mapping
- User Discovery
- How Agile BA works with TIS team:
- UI/UX Designer
- Product Owners' stakeholders
- Dev Team
- TIS programme
- Chanllenges
- Useful BA materials and links
...
This must be done before starting planning, designing or building.
ideally for at least 2 hours every 6 weeks
BA support in the areas below by supporting through either workshops, observation, interview or document sampling etc:
- who the users are and what they’re trying to do
- AS-IS - how they do things currently
- the problems or frustrations they experience
- what users need from new service to achieve their goal (TO-BE)
BA ensure in a user research:
- business needs (objectives) are covered - we look at the bigger picture (we ask the questions WHY....? WHO....?), we look at impact of a project on the business.
- how success is going to be defined and measured are determined; We look at the measurable goals and desired outcome
Artifacts
- Research outcome document; User Journeys, Findings Report, Personas, etc)
Useful link: User research in Discovery for more details/information
...
Agile BA roles: Story Mapping
The BA support the UI/UX designer with in story Mapping to capture user journey.
- It is part of the discovery phase
- It is an effective inception tool to create a product backlog in a visually structured way
Story mapping consists of ordering user stories along two independent dimensions. The "map" arranges user activities along the horizontal axis in rough order of priority (or "the order in which you would describe activities to explain the behaviour of the system"). Down the vertical axis, it represents increasing sophistication of the implementation.
Story Map Structure:
Goals > Activities > Tasks > Stories or Goals>Features>EPIC (Sub- features)>Stories
...
An example of a user mapping below: Manage account
Agile BA roles: User Discovery
Note:
- Before you start building a service, you need to find out whether users need it and whether other services exist
- If you want to spend money on a digital or technology service, you may have to get approval from the Government Digital Service (GDS). Check link for more information
- You shouldn’t start building your service in discovery
- discovery should usually take between 4 and 8 weeks though it depends on size and complexity
- During the fianl week:
- make a broad scope for your project
- write user stories
- decide the features your ‘minimum viable product’ must have
BA support in the areas below by supporting through either workshops, observation, interview or document sampling etc
- who your users are
- users’ needs and how to meeting them, or any needs not meeting
- which services currently meet users’ needs and whether they’re government services or private sector
- how to start developing a new service if discovery finds there’s a user need for one
- the people needed on the team for the alpha phase
- what the user journey for someone using the proposed service might look like
- what to name the proposed service
- how to meet government accessibility requirements
- how you might build a technical solution given the constraints of your organisation’s legacy systems
- the policy that relates to your service and how it might prevent you from delivering a good service to your user
...
Link: Business Analysis Framework (BA activities)
...