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
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 ask open - ended question in workshops
BA support in the areas below by supporting through either workshops, observation, interview or document sampling etc:
- who the users are (B2B/ B2C) and what they’re trying to do (goal), what matters to them, what other goals they have and what other tools they use.
- 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)
...
- 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
...
BA work with Product Owners' stakeholders: Help to capture requirements during stakeholders engagement Help POs with writing the stories and AC's and Confluence updated accordingly
BA work with Dev Team: Pair with devs' on domain specific work as an extra support during sprint
...
- 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.
...
- 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
...
Link: Business Analysis Framework (BA activities)
...