User story mapping

5 Dec

What is user story mapping

User story mapping is a workshop technique that creates a visual representation of product requirements, and orders them based on priority, user theme & time.

The output of user story mapping is a product roadmap that clearly conveys the context of each user story, the horizontal slices of the MVP, and the aspirational scope of the product.

The technique has become popular through the work of Jeff Patton. An example user story map is here:

Shoes website - USM

Reasons to use this technique

The early stages of the new product lifecycle can be a challenging time for Business Analysts. Considerable BA effort can be spent:

  • Capturing initial requirements (e.g. User Stories) & creating a structure around them (e.g. EPICs)
  • Capturing the overall product scope for the new product
  • Prioritising requirements into an MVP and subsequent releases
  • Understanding where to focus the analysis effort (i.e. which areas to initial spec out)

User story mapping will help you visualise the requirements & their context within the overall product roadmap. You will create a visual overview of the roadmap.

How to run a USM session

Organise a workshop with the key stakeholders: product, UX, technology, internal SMEs etc. Ideally you want no more than 10 people (7 + – 2 is the magic number).

Bring post-it notes, pens and plenty of sweets.

Step 1 (kickoff & context)

The BA/PO kicks off the session. They present a summary of the product vision. What problems does the product need to solve? What audience insight do we have? What are our known constraints? What are our competitors doing? What are our aspirations?

An example would be “We want to build a website that sell shoes to teenagers. We have evidence that XYZ opportunity exists and we want to focus on the teenage market etc etc”

This should take 10 – 20 minutes.

Step 2 (identify user tasks)

Each stakeholder should (in silence) write down how a user will use this new product on post-it notes. What do users they need & want to be able to do?

An example would be: “search for shoes”, “browse a website hierarchy”, “view recommended products” “add to a basket” “share on Facebook” etc.

As a tip to ensure you’re capturing the correct detail – they should be written from the user’s perspective and usually start with a verb (e.g. add, share, browse, buy etc). These are the things your users will do with the product.

This should take 10 minutes (depending on the scope of the product).

Step 3 (remove duplicate tasks)

The BA/PO should put the post-it notes on a physical board. Talking about each post-it note, the author should describe what they’ve written and why.

During this process duplicate post-it notes should be removed.

You will end up with something like this:

USM - User tasks

These are your USER TASKS (i.e. things a user does to achieve an objective). They form the walking skeleton.

This should take 15 minutes.

Step 4 (identify user activities)

With the post-it notes on the board, start to organise them into clusters (clusters = based on similarity). Assign each cluster a name.

An example would be: “find a product“, “view a product“, “buy a product“ etc. Where “find a product“ includes “search on site”, “browse a website hierarchy”, “view recommended products” etc.

Order these clusters according to the order in which a user would complete them.

For example: find a product > then view a product > then add a product > then buy a product

Note – if the post-it notes can’t be ordered from a user perspective, then you can order them based on when you plan to pick up the work. Ideally you should organise the items from the user’s perspective, so that reading the activities from left to right tells a story and represents a narrative.

User activities - USM

These clusters are your USER ACTIVITIES. They form the backbone.

This should take 15 minutes.

Step 5 (confirm all activities & tasks are captured)

With the USER ACTIVITIES and USER TASKS on the board – explore the user journey and see whether you have captured all the activities and tasks. Thinking in terms of user personas can assist. Drill down into the activities to see if there’s additional detail you can add.

Use this as a time to confirm that you’ve captured the scope of the system. If there are activities or tasks that don’t fit into the main narrative (e.g. user can localise the website language), add these items to the end of the map.

This should take 20 minutes.

Step 6 (identify user stories)

The final level of detail for the map is USER STORIES. I haven’t encountered a body related synonym for user stories – continuing with the theme of walking skeleton & backbone, we could suggest body of work?

Each USER TASK will have user stories. Explore the user tasks in additional detail – capture and frame that detail as user stories (each user story requires a title, a description, and any relevant detail).

For example within the “search on site“ user task, there could be a user story to:

  1. Search based on keyword (AS A user, I WANT to search for shoes using keywords such as Nike, Jordan, trainers SO THAT I can find my desired product quickly)
  2. Search based on colour
  3. Filter by brand
  4. Search based on shoe size

The user stories are designed to be a placeholder for a conversation – a snapshot of what the user needs and why. Don’t try to add too much detail. They should meet the INVEST criteria.

This step can take some time, depending on the product. Either take a break until starting the step, or run it as separate sessions.

Step 7 (prioritise user stories)

With the product team steering this, work as a team to put user stories in a priority order, from highest priority to lowest priority. This can be a difficult task – compare the relative value of each user story to another.

Now draw a vertical line to slice to roadmap. This line represents the minimum viable product (MVP), you can draw lines for additional versions of the product too.

MVP - User story mapping

Step 8 (next steps)

You should now have all the user stories defined, prioritized and organized by theme.

The BA can take away each user story and work on them separately, adding acceptance criteria/detail in order to allocate them into a Sprint. The great thing about this technique is that each user story now sits within the context of a user journey.

Shoes website - USM summary

Benefits of user story mapping

+ It visualises the product backlog – a USM is easy to present & understand compared to a list of JIRA tickets. A picture is worth a thousand JIRA tickets 🙂 You can put it on a Sprint board.

+ It radiates information including: the context of items, the relative priority of each item, the groupings of work and the MVP.

+ It’s hierarchical – it covers the high level themes and the more granular user stories. You can see the big picture, the finer detail and the aspirational vision.

+ It encourages valuable slicing of functionality – the lines drawn from left to right slice the backlog so that you don’t build all of the search stories and then run out of money before you develop the buy stories.

+ It organizes the roadmap based on how users will use the new product. By focusing on user behaviour rather than how systems interact, you build a product around the user needs.


  • Can this be applied to any type of product?
    • I think so. Provided it has end users. I’ve applied the technique to a feature which allowed users to sync their favourite items. On the surface of it, the feature was essentially a read/write capability – but we were able to convey it as a set of user tasks.
  • Would you ever create multiple user story maps for one product?
    • I have never done this. If your product is the Amazon website then you may need multiple maps – but hopefully your product isn’t that large.
  • Are there any downsides?
    • The user story map doesn’t replace your requirements/JIRA tickets. It’s essentially a way to visualise them within the context of the roadmap. As the system changes you’ll need to update the USM as well as your requirements/JIRA. As such, it’s a product artefact that needs maintaining.
  • What if you have no idea what the product is?
    • The technique generally assumes there is a product vision around which to hang these tasks/stories. If you have very little idea about the new product (e.g. “we want to build a page on the website where users can see things that most interest them”) then you can still use this technique. I’d recommend some form of upfront thought about what you want that page to do by the product team & a warm up activity for the group before step 2 (e.g. crazy 8’s).
  • Aren’t user tasks just another type of user story?
    • User tasks can be thought of as high-level user stories e.g. “searching for a product“ is a task that can include multiple user stories (search by keyword, search by shoe size, filter by brand, search by colour). The essence of activities vs tasks vs stories is that they’re hierarchical user needs. Exactly what they are depends on what product you build.

Product exercises – postcard from the future etc

7 Apr


Below is a set of exercises I have run or participated in – that are intended to facilitate product discovery & product development early in the project lifecycle. These exercises help teams generate a product vision and solicit high-level features/themes around which a prioritised product backlog can be generated.

Postcard from the future


  1. Split the group of participants into pairs. Participants include senior project stakeholders (UX, product, tech etc). Try to create cross discipline pairs.
  2. Assign each pair a user persona. User personas are designed to provide insight into your market by identifying how different types of consumer will use your product. An example persona which you could assign to a pair would be “Mobile Mark. 24 yrs old London professional with the latest iPhone. Likes new technology. Regularly checks Twitter etc …”
  3. Ask each pair to write a postcard from the future as their assigned persona. An example would be “imagine we have just launched our new responsive website. Mobile Mark is a tech savy user. He is so happy with our new website that he has decided to write a postcard to our team.” A pair would then write a postcard as Mark – about why he loves the new responsive website.
  4. Once the postcards have been been generated – ask each pair to introduce their assigned persona to the wider group and present that persona’s postcard from the future. Allow the wider group to ask any follow-up questions.

Note – I have also run this session with Tweets/Vines from the future. The Twitter format is particularly useful for capturing a concise summary – often with the single most important feature. The Vine format is an interesting variant, it allows people to be more creative and tell a story (e.g. “Mark gets on the bus, checks the website, jumps up and down in excitement and spills his drink, Tweets his friend”).





This exercise is useful for:

  1. Getting senior project stakeholders to think about the product from a persona’s point of view. It’s easy for stakeholders to think of features their own viewpoint – this exercises allows senior project stakeholders to empathise and create a vision from their user’s perspective.
  2. Identifying “warm fuzzy features”. It’s a great technique for discovering features that would delight your users e.g. everytime Man Utd score Mark’s phone cheers, otherwise it boos”. The format and persona based nature of the exercise encourage creative and out-of-the-box thought.

Hopes and fears


  1. The facilitator will introduce the project goal to the stakeholders e.g. “We are planning to create an Apple watch app. Here are several potential designs. Before we proceed any further – we want to ask everyone for feedback about their hopes and fears for this project”. Stakeholders in this context are anyone who has an interest in the success of the project.
  2. The facilitator will ask stakeholders to write down their hopes and fears in silence. These hopes/fears are then placed on a board.
  3. Once all the feedback has been captured on the board – the facilitator will talk through the hopes and fears. The facilitator will: seek clarity on specific points, encourage an open dialogue on each item, seek agreement and identify common themes.
  4. The hopes and fears will then be taken away and captured in the project space (e.g. a wiki space).


  1. This exercise allows stakeholders to convey their aspirations and perceived risks early in the project lifecycle. It reduces project risk and builds consensus.
  2. Individual hopes can form the basis of high-level themes or features. For example “I hope we can provide content that is useful to a user’s context”. This hope may become a feature to “vary the content/format depending on time of day”.

Now, next and later


  1. The facilitator will hold up individual features (features are prepared in advance). They will describe each feature and encourage an open dialogue with the audience. The audience is typically senior project stakeholders.
  2. For each feature, detail and clarity will be added through discussion. The audience will be asked to assign each feature to either the now, next or later column. If too many items are added to the Now column then the facilitator should challenge this.
  3. Once all features have been presented to the audience – the facilitator will review the content in each column. The facilitator will confirm whether each column contains a logical slice of features and verify consensus within the group. Items can be moved. Particular emphasis should be given to the Now column – because these features could become the 1st phase of the project.


  1. Primarily used for early product prioritization. The “Now” features can become the MVP. The exercise produces the phases required to achieve a vision.
  2. The Now, next and later technique is similar to MOSCOW prioritisation – however it offers a slightly fresher format.

1st published BA cartoon

7 Oct

Happy to announce that Brian the BA has reached a wider audience:

Product Backlog Refinement in SCRUM

16 Jun

Within the Scrum Framework – there are numerous GASPs (Generally Accepted Scrum Practices). The following 4 meetings are all GASPs:

• Sprint Planning
• Daily Stand-up
• Show and Tell/Sprint Review
• Sprint Retrospective

There have been efforts to include a 5th meeting to the list of GASPs:

• Product Backlog Refinement (PBR session)

The overall aim of this meeting is to manage the product inventory and ensure that the product backlog (i.e. anything outside of a Sprint) is up-to-date. This is done through the following PBR activities:

I) Refinement:
• Progressively breaking down large items (EPICs) into smaller items (features/use cases etc) that can be implemented in a single Sprint
• Grouping items based on commonality (technical delivery/product goal etc)
• Adding detail – such as acceptance criteria – to items in order to generate a common understanding

II) Estimation:
• Pre-Sprint, high-level estimation of items in the product backlog will facilitate delivery planning
• Methods include – story point estimation (e.g. planning poker on the Fibonacci sequence), t-shirt sizes, bucket estimation, blink estimation

III) Prioritisation:
• Items are prioritised according to business value (this is primarily identified by the Product Owner/stakeholders/user data)
• Items are independent as per the INVEST criteria – therefore the order of items on the product backlog leads to a prioritised Sprint backlog

IV) “Ready” state:
• Items are discussed – with issues/questions/actions being identified
• Agreement on what needs to be done in order to get items into “Ready for development”/”Ready for Sprint”

V) Communication:
• Team understands the bigger picture – i.e. the vision beyond the current Sprint

VI) Ideation:
• New, high-level user stories are discussed and added to the Product Backlog
• Bringing together members of the business and technical team to discuss ideation facilitates collaborative product development within a cross-functional team

I) Timing:
• Regular – product priorities/understandings are dynamic. The product backlog must therefore be responsive to change. It is recommended that PBR sessions are held every Sprint or 2
• Scheduled – Typically mid Sprint in order to avoid conflict with the Sprint Planning/Show and Tell/Retrospectives
• Duration – Timeboxed – typically to 1.5 – 2 hours

II) Participants:
• The Product Owner is primarily responsible for the Product Backlog. The Scrum Master is responsible for facilitation and the removal of obstacles. Attendance of both is therefore mandatory
• Team members – invited – however attendance is optional. Details of which stories will be discussed in the session should be provided in advance (this enables users to decide whether or not to attend)
• Small number of stakeholders can be invited to assist with prioritisation. Representation from both the business and technical team is preferred

III) Agenda:
• The entire product backlog is not discussed. Instead the agenda should cover items that are likely to come up in the next 3-4 Sprints
• The session should aim to achieve the following:
•• Agreement on story breakdown/high level definition
•• High-level estimation
•• Item prioritisation
•• Agreement on actions necessary to get items into a “Ready” state
•• Discussion of any new ideas
• At a high level – the aim of the PBR session is to ensure that items in the Product Backlog meet the DEEP criteria (Detailed Appropriately, Estimated, Emergent and Prioritised)

Applying Agile principles to requirement analysis

23 May


The Agile methodology originated within the software development industry. Since its inception in 2001 – Agile has expanded beyond an initial developer-centric community – to being embraced by multi-discipline teams working across numerous industries.

The antecedent of Agile within IT was the Waterfall methodology. The Waterfall framework consisted of a series of sequential, discrete phases – with each phase conveniently mapped to a role/responsibly:

Analysis Phase             -> Requirement Analysis (Business Analysts/Product Owners)

Design Phase                -> UX (Designers/Usability Experts)

Development Phase  -> Software Development (Developers)

Testing Phase               -> QA (Manual Testers and Developers in Test)

Delivery Phase             -> Release Management (Project Managers)

Due to the increasing popularity of Agile – requirement analysis has been encouraged to transition from being a stand-alone phase owned by BAs/POs – to become a project facet that can incorporate Agile principles.

In what ways can requirement analysis adopt Agile principles?

Collaborative requirement analysis

Prior to Agile – the practice of the development team being presented with an upfront, non-negotiable, detailed requirements document (BRD/functional specification etc) was common. With the advent of Agile – requirement analysis should no longer be restricted to the interaction between BAs/POs and the business – instead we should embrace collaborative requirement analysis:

A popular collaborative requirement technique is the “3 Amigos”.  This process involves the developer, BA and QA discussing the requirement specification in a workshop. Each Amigo will offer a unique perspective – through discussions the Amigos will identify edge cases, undefined requirements, opportunities and potential reuse. The 3 Amigos technique can also reduce the risk of incomplete features being pushed into development by the product team – requirement specifications must be pulled into development when they have been reviewed and accepted by the 3 Amigos.

Collaborative requirement analysis facilitates a project-wide sense of ownership – and also communicates a common understanding of what features need to be built. Collaborative requirement analysis produces more robust specifications – and reduces the role-based silos that can exist on projects.

Detail as an emergent property

Agile artefacts such as technical spikes and development iterations mean that high-level requirements can be considered sufficient at project initiation. Low fidelity requirement assets (e.g. user stories /”back of the napkin” designs) should be employed on Agile projects:

Just-in-time requirements analysis (JITRA) has a concept that requirements should only be specified at the level of detail required for upcoming development. JITRA states that the further in advance of development requirements are defined – the more probable that requirements will become out of date, leading to rework and wasted effort.

Detail should emerge when it is required – which is typically towards the middle/end of the project lifecycle. Initial requirement analysis should be focussed on business justification and solution scope.

Embrace change

Specifications will evolve throughout the project lifecycle; all team members must acknowledge the benefit of responding to change. Adapting to changes in circumstances/urgency/understanding is crucial – requirement analysis should be considered an iterative rather than exhaustive process:

In terms of systems theory – project teams should be viewed as open systems. As the system will tend towards a steady state – change should be encouraged and communicated at an organisational level. Regular priority sessions, stakeholder workshops and competitor reviews should be used to mitigate resistance to change.

Incorporating feedback is crucial to the success of a project. Requirements are not unchangeable statements – they only reflect the current and expected situation, both of which are liable to change.

Necessary documentation

The adoption of Agile principles does not mean that requirements should not be documented. Requirement documentation is vital for developers, QA and the business stakeholders:

The principle of living documentation should be embraced. This means that all documentation needs to be accessible and up-to date. Business users, developers and QA should be able to request requirement changes. Documentation is most valuable when it is understandable by all team members, available and responsive to change.

Lightweight documentation such as feature files and high level process maps summarise the output of the requirement analysis process. The Agile methodology encourages appropriate documentation – superfluous detail is wasted effort; Agile does not negate documentation.

Continuous process improvement

Requirement processes should not be viewed as immovable obstacles. Instead these processes should evolve and adapt to meet the needs of the project. Where a process or artefact ceases to produce the expected value –it should be reviewed and changed by a self-organising team:

Retrospectives are a popular technique for identifying improvement opportunities. Team members meet to discuss what the team needs start doing, stop doing, and continue doing. Regular (every 2/3 weeks) and actionable retrospectives provide an open forum for continuous process improvement.

Requirement analysis processes (to-be-analysis, process mapping, stakeholder workshops etc) can always be improved. A technique that is effective for one team – may not be effective for another – or at least may require several modifications.

Continuous delivery

The Agile methodology promotes product iterations and regular releases. In order to align with this ethos, requirement analysis must produce a constant output – a steady flow of requirements will avoid the “big bang” requirement delivery that characterised the Waterfall methodology:

Minimum Viable Product (MVP) provides the scope of requirement analysis. The MVP will be delivered in multiple iterations – requirement analysis must be constantly baselined against the MVP and ensure that there is a sufficient specification available for each delivery.

Shorter delivery timescales encourages more frequent requirement analysis output. Specifications should be aligned to the MVP – features need to be deliverable and contribute to the MVP vision.


Iterative, collaborative Agile development has replaced the sequential Waterfall development methodology. Prior to Agile – the product team could hand over a list of detailed requirements – which would then be used by developers to build the product. In order to align requirement analysis with Agile development practices – the following principles need to be applied: requirement collaboration, iterative specifications, embracing change, necessary documentation, continuous improvement and continuous delivery. By adopting these principles requirement analysis will transition into the Agile world, produce better specifications and ultimately lead to greater quality products.


22 May

GAMIFICATION is the application of gaming constructs to non-game contexts.

Gaming constructs:

• Immediate rewards/feedback (e.g. badges, points, likes etc)
• Measurable progress path
• Task/challenge based
• Problem solving
• Fun factor
• Player centric

Non-game contexts:

• Personal finance (
• Location-based social networking (
• Technical forums (
• Test driven development ( – requires Eclipse)
• Software development tutorials (

Is Gamification effective?

The aim of Gamification is to apply the mechanics of gaming in order to reward user engagement and encourage a sense of achievement.

As a buzzword – Gamification is trending ( and there is evidence that Gamification can produce some benefits:


However – there have been MANY criticisms of Gamficiation. These range from:
• Gamification relying on extrinsic rewards rather than intrinsic motivation. This produces a failure to offer long-term, sustainable value. As with Foursquare – the appeal offered by Gamification is typically one of novelty
• Overreach. It’s been adopted too far beyond its intended remit – “Gartner Says by 2014, 80 Percent of Current Gamified Applications Will Fail to Meet Business Objectives” (
• My favourite criticism is here:


Aspects of Gamification are appealing,  when applied correctly there is evidence that Gamification can increase initial engagement. However as an approach to generate meaningful, long term changes – the jury is out.

If you’ve read this far – congratulations you’ve won a “Gamification badge” 🙂


Brian the Business Analyst – part 3 – young Brian visits a career counsellor

29 Apr


How to measure Agile maturity on your project

28 Apr

What is “Agile”?

The concept of “Agile” was popularised in 2001 with the publication of the Agile Manifesto ( The manifesto set out a number of principles which – when successfully applied – would improve the process of software development.

Over time these Agile principles – valuing individuals and interactions over processes, responding to change, collaboration etc – were applied to projects in various industries. “Agile” made the transition from IT to general management practice in a similar manner to lean/six sigma’s evolution from its manufacturing origins.

With its increasing popularity – Project Managers were widely encouraged to implement Agile principles in order to successfully deliver projects (

Why measure Agile maturity?

1) Let’s imagine the following scenario:

You’ve heard that Agile is popular with other PMs – but you’re not sure about it. You decide to try Agile on your project. You invest £10,000 on staff training and purchasing Agile artefacts (an online dashboard, Sprint boards etc). One year later – you want to find out whether your investment was worthwhile. You measure the team’s current delivery (time/cost/quality metrics) and compare this against an earlier benchmark. You notice very little improvement.

As a PM – do you attribute this to the team’s failure to implement Agile principles (i.e. due to a low level of adoption)? Or was Agile the incorrect methodology for this team (i.e. due to the nature of the product would a more structured approach have had greater efficacy)?

Without a measure of Agile maturity – how can you answer these questions?

2) In another scenario:

You’re a PM who is completely sold on “Agile”. You believe in it passionately – the more Agile a team is the better. You have a total of 7 teams across the business using Agile.

How can you identify the Agile improvement areas for each of the 7 teams? How can you provide feedback on their Agile performance?

3) Last scenario:

You dislike Agile intensely. It’s a methodology that has being extended to fit every size/structure of team. You use Waterfall – and want to convey that this approach works for your team.

Imagine that you could measure your team’s success using the standard metrics – and also show that this success has been possible without being “Agile”. Perhaps then there would be less pressure from management to adopt Agile principles.

Broadly speaking therefore – the pragmatist (scenario 1), Agile evangelist (scenario 2) and Agile sceptic (scenario 3) would each benefit from the ability to quantify Agile adoption. So what types of Agile assessments are available?

How to measure Agile maturity?

There are 4 widely available, self-administrable, free assessments that can provide teams with a detailed breakdown of performance across key Agile areas:

1) Mike Cohn & Kenny Rubin ( This assessment measures a team’s performance across 7 dimensions: teamwork, requirements, planning, technical practices, quality, culture and knowledge creation. With approximately 100 questions – this is one of the most detailed assessments available online.

2) Thoughtworks ( Consisting of 20 questions – and providing a detailed summary report – this assessment was developed by a leading consultancy. The assessment is best administered as a group exercise- as this encourages dialogue and leads to a more balanced viewpoint.

3) The Nokia Test ( This is one of the oldest assessments available – and was produced by Jeff Sutherland (a key figure in the Agile community). The Nokia Test focuses on the iterative nature of Agile and the adoption of the Scrum framework.

4) Agile Karlskrona test ( or an incredibly simple self-assessment that provides a team with a basic snapshot of their performance.


The 4 assessments mentioned above provide valuable feedback: improvement areas are flagged and successes are recognised. They also encourage dialogue throughout the team in terms of best practices.

It is worth adding however that “Agile” is based on a descriptive manifesto (e.g. you should value customer collaboration) – rather than a prescriptive manifesto (e.g. you should produce a customer collaboration tracker which should be reviewed biweekly with the PMO team). The origins of Agile (in terms of a descriptive manifesto), and the lack of a definitive maturity model, mean that although measuring Agile maturity is worthwhile – it is an imprecise science.

How 2 types of BA can transition from Waterfall to Agile

25 Apr


Most BAs have experience of traditional Waterfall development. Within the Waterfall framework there are the following sequential phases:

-> Analysis
-> Design
-> Development
-> Testing
-> Delivery

Waterfall projects kick-off with an “Analysis” phase. This is designed to assess the problem and scope out a solution (as-is and to-be analysis). The project will then progress through the remaining discrete phases – until the product is delivered.

In the same way that the “Design” phase had designers, the “Testing” phase had testers, the “Analysis” phases had analysts (BAs).

After working on a number of Waterfall projects – I noticed that 2 types of BA evolved.

TYPE A (“Specialists”/”Purists”)

• These individuals were lucky enough to work in a mature BA practice. The analyst role was well established – BA deliverables were often standardised (e.g. BRD templates/peer review)
• They focused primarily on the “Analysis” phase of a project – in the same way that designers focused on the “Design” phase
• When the “Analysis” phase was complete – they moved onto another project. It wasn’t uncommon for a BA to work on multiple projects/workstreams simultaneously

TYPE B (“Generalists”)

• These individuals almost had to define their own roles. They worked in organisations where the BA role/responsibilities weren’t fully understood
• BAs were treated as generalists. They were often asked to “do a bit of everything”
• Their deliverables stretched across the project lifecycle and included: requirement specs (“Analysis” phase), wireframes/low fidelity mock-ups (“Design” phase), clarifying queries from the dev team (“Development” phase), testing the product (“Testing” phase) and creating user guides/training end-users (“Delivery” phase)
• These individuals worked on individual projects – and were often influential

How can these 2 types transition into Agile?

TYPE A (”Specialists”/“Purists”)
• These individuals can continue to focus on specifying new features (i.e. requirements/acceptance criteria). In order to maintain a purist approach they will need to work 1 Sprint ahead of the developers. Most of the work they produce will go into the following development Sprint
• Career progression -> Senior BA role

TYPE B (“Generalists”)
• These individuals can continue to focus on a diverse range of deliverables: they can produce requirement specifications, provide design feedback, facilitate product planning, support development and perform ad-hoc testing. In order to provide the developers with a constant backlog of work – they will need to spend 50% of their time on the current Sprint and 50% of their time on the upcoming Sprint.
• Career progression -> Product Owner (possibly also Scrum Master role)


What is your opinion? Are there TYPE As and TYPE Bs? Where do they fit in an Agile world?


Brian the Business Analyst – part 2

24 Apr