Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 32 Next »

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

  1. Agile BA role around:
    • Story Research
    • User Mapping
    • User Discovery
  2. How Agile BA works with TIS team:
    • UI/UX Designer
    • Product Owners' stakeholders
    • Dev Team
    • TIS programme
  3. Chanllenges
  4. Useful  BA materials and links 

Agile BA roles: User Research

Note:

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

Structure based on 'User Journeys' : User > Goals > User Journeys > Actions > Stories.

Structure based on Non-functional requirements NFR:  NFR > Requirement > Story


An example of a user mapping below: Manage account

A graphic illustrating the activities and steps for a user with the addition of user stories

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:
    1. make a broad scope for your project
    2. write user stories
    3. 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

Artifacts 

  • a prioritised list of user needs
  • a prioritised list of user stories
  • a list of stakeholders, and information you’ve got from them about existing services

Useful link: How the discovery Phase work for more details/information

How Agile BA works with TIS team

Work with UX/UR, BE/FE devs and POs and facilitate for solution design (should not really be just a BA specific job as in a waterfall setup)

Likely questions BA  might ask during solution design:

  • what are the all possibilities ?
  • would a solution be an option to consider?
  • why have we not considered a particular solution?

BA work with UI/UX Designer:

  1. Support in workshops during User Recovery (User Research and Mapping)
  2. Helps with writing the stories and Acceptance Criteria and Confluence updated accordingly

BA work with Product Owners' stakeholders: Help to capture requirements during stakeholders engagement

BA work with Dev Team: Pair with devs' on domain specific work as an extra support during sprint

BA work with TIS programme:

Challenges 

Writing up stories - need to come up with a way to get this done in a collaborative way (not happening at the moment) but everyone wants user-centric stories

  • Can't do this without the users and collaboration with the PO's
  • Get PO's to involve us more with their stakeholders meetings so we can tease out user needs and take those to dev team for scoping/solution designing etc.

DITAG

  • Are there going to be specific BAs resource for this? If so when?
  • Initial ideas assessment - If not part of TIS then, avoid spending much time on?
  • Need Clear scope of DITAG?

Project team communicating directly with DEV workstream, including us BA's

  • if they need our input it should come from the PO's as they work directly in Project Managing the work the PO's do.
  1. Design and Build Digital Services for the NHS
  2. User Research 
  3. How the discovery Phase works

Link: Business Analysis Framework (BA activities)

  • Understand Context- Business Objectives
  • Investigate Situation
  • Consider Perspectives
  • Analyse Needs
  • Evaluate Options
  • Define Requirements
  • Deliver Change

Common Requirements Gathering techniques

  • Brainstorming
  • Interviews
  • Observation
  • Shadowing
  • Workshops
  • Prototypes
  • Visual modeling



Op




Open the Business Analysis Framework


  • No labels