Skip to main content

Author: Nick Stowers

4 key activities for a Business Analyst in the Alpha phase

On one of my earlier blogs, I described what I thought are the 3 key activities a BA should be doing when they were in a Discovery phase of a project.

The feedback I received was positive so I thought I’d give, what I consider to be are the 4 key activities are for a BA in an Alpha phase.

So what exactly is an ‘Alpha’?

In the UK, the Government Digital Service (GDS) defines the phases in an Agile delivery lifecycle as; Discovery, Alpha, Beta, Live and Retiring the service. GDS also cover in detail how the Alpha phase works, but what’s not covered in the article is what each role in a delivery team does within an Alpha, including Business Analysts.

If you’re not familiar with the names of these phases, they are the same for pretty much all Agile project delivery. The most common themes I’ve come across are;

  • Concept, inception, iteration, release, production, retirement

Moving Discovery outputs in to an Alpha

Key outputs from the Discovery the BA should have been heavily involved in include:

  • Stakeholder analysis
  • Understanding and defining the problem
  • Starting the product backlog

Each of these outputs now need to be taken through in to Alpha by the BA and here’s how.


Stakeholder analysis – Use your stakeholder knowledge

An Alpha to me is the exciting part of the Agile delivery lifecycle as this is where you actually start putting ideas and concepts in front of users and you learn ‘how’ they will really interact with your product and get valuable feedback. To ensure you get as honest and realistic feedback as possible, it’s important to try and create as real-life scenarios as possible to test the prototype with users. To do this, the BA should use their knowledge of working with stakeholders in Discovery and take this in to the development of the prototype with the designers on the team. After all, if you were the BA involved in Discovery, one of your key outputs is understanding the users and their needs, and that includes the needs of the business. Therefore, armed with this insightful knowledge, you should work closely with the design team to ensure they also understand the users. 

Understanding and defining the problem – Keeping the product vision in view

During Discovery, the team will have (or certainly should have) defined the problem that needs to be fixed and from that, a product vision should also have been defined. Roman Pichler has an excellent article on how to create a compelling product vision which I highly recommend you read as well as all the other articles he has on his website. 

For me, the product vision is one of, if not the key outputs from Discovery and is something that should be visible and referred all the way through the delivery lifecycle. All too often I’ve seen the product vision put up on the team wall (or worse, in a folder on the Product Owners laptop) but no one seems to take any notice of it and it becomes just a part of the wall space along with user research findings, sprint boards, etc. To make sure the product vision stays in view, and you have wall space, have it beside your user story map (coming up in the next section). Pretty much everything that’s in your user story map should stem from the product vision, so keep them close together.

Starting the product backlog – Make sure prototypes stem from user needs (building your user story map)

How prototypes are developed is different for all teams but in my view, the quicker you get to an interactive prototype, the better. I’m all for sketching out designs to protect costs and save time, but only once a prototype is in the hands of users and seeing their interactions with it, will you start to get valuable (and workable) insights to develop the prototype further. And remember, as the BA, you’re going to start building the product backlog based on the findings and create your user story map. If you’re even half serious about being a Business Analyst, I don’t need to tell you the powerful impact of user story mapping but if you need reminding, here’s Jeff Paton (the guy who came up with the idea of user story mapping) showing you how to create one. 

Help the team design iteratively

Having your user story map on the team wall (or online if you are a in several locations. I recommend as a user story mapping tool) is a great way to galvanise the team and ensure what you’re doing aligns with the product vision (hence having the vision next to the map). As we know, agile delivery focuses on building products in an iterative way and this principle should apply to designing prototypes in Alpha. I quite often see designers go off and start building complex, end to end user journey. For this very reason, having a user story map will encourage the design team to not think too far ahead. After all, your map will have an ‘MVP’ (or Release 1 if you’re not comfortable with the term MVP) swim-lane where you’ll define as a team what features will (or might) go in the MVP and this is what the design team should be focusing on prototyping.

And finally…

Don’t misunderstand me, and this is based on the feedback from my ‘BA in a Discover’ blog, these are not the only 3 activities a BA will carry out in an Alpha and you will no doubt carry out more than this (e.g. writing the user stories for Beta, working with technical architects/software developers to ensure what is being designed and tested with users can actually be built, continually developing the backlog, etc) however I’ve seen projects where the BAs have not been involved much in the design process and this which has led to problems further down the delivery process. Remember, you as the BA are the bridge between the design team and the developers/testers!!

An Alpha (or iteration) phase can last several weeks and if you as the BA follow these activities, you’ll ensure the product is designed with the users in mind, in an iterative way, and that when you get to the Beta phase (blog coming soon), your product will be delivering the value defined by the product vision.

What your burndown charts are telling you

When I was introduced to scrum, the burndown chart was a tool that was highly emphasised however I feel the purpose has changed

from it being a tool to predict (to a certain level) timescales for delivery to a tool that measures a team’s productivity… other words, the focus is on the number of points cleared which in my eyes, drives some adverse behaviours.

In this blog, I’d like to show some example burndown charts I’ve come across in teams I’ve been part of as a Business Analyst and what they should be telling you about how the team is operating. I’ll also offer some suggestions to fix what could be barriers to becoming that high performing agile team we strive to be.

So what is the purpose of a burndown chart?

A couple of quotes:

‘Burn down charts are a run chart of outstanding work. It is useful for predicting when all of the work will be completed’- Wikipedia, 2019 <“>>

We can take it from both of these quotes that the purpose of the burndown chart is to be able to visually see progress through a sprint, however I’d like to emphasise Mike’s point in his description that it ‘is a way to clearly see what is happening…during each sprint’. On many of the teams I’ve worked on, if not most, burndown charts are not reviewed at all but only looked at if someone outside the team wants to see them.

I’m well aware every burndown chart will have its own unique story behind it so when I give what I think are reasons behind the chart in the examples below, I’m only hypothesising from my own experiences. And while the burndown doesn’t tell the whole story, in my experience the analysing of them (with the whole team of course) has always improved the ways of working and that is the purpose of this blog.

Note: in the examples below, each sprint is 2 weeks long with the grey line depicting expected burndown with the red line the actual.

Example 1

The ‘Manhattan skyline’ burndown

BATimes APR2 1 2020

Possible reasons

Ok, it’s not exactly like wonderful Manhattan but you get the idea (up and down peaks across the sprint). I think the two key parts of this burndown are the long flatlines at the beginning and midway through the sprint and the spike 3 days in. While this doesn’t affect the sprint points (what points/stories have been added have then been removed), it suggests the team weren’t confident of completing what was going in to the sprint for a significant increase (30 points). Or possibly, the stories weren’t ‘ready’ for the sprint. Also, have the team bitten off more than they can chew during sprint planning as there are 10-20 points left on the table at the end of the sprint?

How to fix

During sprint planning, ensure all the stories that are sprint candidates have met the team’s ‘Definition of ready’ and the team are confident that those stories that are being taken can be completed within the sprint. This may take some time for the team to get to this point as estimation and sprint planning (for me) are the two areas of Scrum that take most time before the team are comfortable with both aspects. And in my experience, if the team get these elements right (well estimated stories and confident planning), sprints tend to go pretty much as planned.


Example 2

The burn down-up-down-up chart

BATimes APR2 2 2020

Possible reasons

I think it’s fair to assume this team is clearly having problems as you can plainly see but what might be the potential cause of this erratic burndown (or burn across!!)? Firstly, it’s clear the team have taken on way too many points for the sprint. Of course, there could have been an issue near the end of the sprint that caused the team to stop developing but even so, to fall short by 30+ points should be saying something. Long flatline periods suggests stories weren’t small enough to deliver incrementally. Large increases in points mid-sprint suggests the team have not been disciplined enough in saying ‘no’ to new stories being added. If these stories had not been added (20+ points), then the team may have achieved its target.

How to fix

Don’t be fixated by how many points can be done in a sprint. Just because the team did 60 points in the previous sprint, don’t assume the team can do it again the following sprint. I’m a big fan of Mike Cohn’s ‘Capacity-driven planning’ and I feel it’s the team’s responsibility to confidently be able to say, ‘yes, we can commit to everything in this sprint’. In velocity-driven sprint planning, I tend to see the thought process of what was achieved last sprint and therefore what stories can we cram in to achieve the same number of points or more. I think this approach is counter-productive and brings wariness to the team’s ability to confidently commit to the sprint. Therefore, ask the question, ‘what can we confidently achieve in this sprint?’ as opposed to ‘how many points should we do in this sprint?’

Example 3

The Flatliner

BATimes APR2 3 2020 

Possible reasons

My first thoughts on seeing this burndown was, ’should you even be using agile as a framework for delivering your project?’. I think you’ll agree that from day 1 of the sprint, 35 points have been added before work’s even started. Then there are no points (or virtually no points) cleared for 8 days before a big drop of 20 points and with still 40+ points left on the table. It could be this team is very early in its agile journey and therefore are unclear on their velocity (hence so many points) but still, loading up a sprint with no idea as to velocity suggests immaturity of an Agile delivery framework.

How to fix

In my view, the type of work being carried out by the team might suggest they’re unable to deliver iteratively and therefore may be better suited to a Kanban than a sprint approach. It could be they require the use of an Agile coach or Scrum Master for a period of time to set them on the right track and start from a position where they can clear what stories they take in to sprint and build up their velocity.


I hope those reading this are familiar with these types of burndown charts or if you’re new to Agile and you’re utilising burndowns, my point here is to make sure you use them to analyse how the team is performing and how that performance can be improved. Of course, your retrospectives are the perfect forum to do this.

I should make a couple of points though. Firstly, don’t look at a burndown chart in isolation. I’d look at the last 3-5 to see if there are patterns emerging before you embark on working to improve. Do they look the same or do they look completely different over a period of sprints?

Secondly, don’t place too much emphasis on them. You might think that’s odd as that’s what this blog is about however, as I mentioned, each sprint is unique and each burndown will have some sort of story behind it so use them as a discussion point for the team to improve, and not the be-all and end-all to improve the team’s performance.

As a Business Analyst, I nearly always find the reason why teams don’t deliver in small increments during a sprint, and therefore creating the burndown chart examples in this blog, is down to the user stories. No that user stories are the be all and end all but invariably I find it comes down to the stories either not following the INVEST model or them not being ‘ready’ for the sprint. If you get this part right then your sprints should run smoother and your burndown chart will reflect that.

So don’t ignore your burndowns (or burnups if that’s your preferred method), and if the team’s struggling to complete its sprints, spend some time analysing them to see where the team can improve.

Joining the dots: Working with an Agile development team

I’ve read lots of articles and books on Business Analysis tools and techniques and when to use them in the project lifecycle.

What I haven’t seen so much of is how the BA works with the different roles in an Agile development team. My previous blog went into the change for a BA working in a Waterfall framework to Agile which touched on this subject, so here I want to delve in to how you use the tools and techniques we all know so well and how you work with the right people to ensure the outputs from those techniques are effective. It’s based on the British Computer Society (BCS) Foundation in Business Analysis course headings for those who have that certification.

Investigate situation – uncover issues and problems

As we know, this stage is about understanding what the problem is. The techniques are used mainly in a Discovery phase and is very heavy on stakeholder engagement. However, the skills you use are very closely linked to those of a User Researcher. Interviewing techniques may sound very simple and straightforward but for those who have tried it, it’s not easy. Understanding what are open and closed questions and picking out the important information from the other ‘noise’ is difficult. When interviewing to stakeholders, It’s very easy to:

  • Lose focus of the interview (go off track)
  • Not make the most of the time you have with the interviewee and end up with follow up conversations
  • Not get all the information you are after (again, resulting in follow up conversations)

Working with a good User Researcher, they will show you how to go about creating an effective discussion guide that allows you to not only maximise the time you have with the person you’re interviewing, but also capture all the pertinent information you need in one go. Stakeholders are busy people and may not want to be contacted numerous times.

If you have Subject Matter Experts (SME) as part of the agile team for the Discovery stage, then you will be spending quite a bit of time with them to understand the ‘As is’ processes. Don’t just use them for information though, get them involved in articulating the problems, whether it be a rich picture, mind map or emotion map. Making them feel part of the team will build relationships that you might need to call on later in the development of the product.

Consider perspectives – stakeholder identification and analysis

Getting to firstly identify the stakeholders for your product/service will involve most of the development team on board at that time. Typically, this will be a Product Owner/manager, Delivery Manager (Scrum master), User Researcher and SMEs.

Stakeholder identification and analysis (e.g. interest/influence matrix) sessions should be carried out with the whole team but the BA should be working closely with the Product Owner to understand those stakeholders in the high interest/high influence category which you will need to be managed. While you may not be directly involved in engaging them, you will need to understand their perspectives as they may well see some of your outputs (e.g. problem identification, cost/benefits analysis)

Analyse needs – identify improvements

After the Discovery phase is completed and you’ve got the go ahead for Alpha, now it’s time to get (for me) in to the exciting part of product development……identifying potential solutions to problems.

This for me is the part of product development where the BA really starts to put in practice the work they’ve done in Discovery and develop those relationships with nearly all of the other roles on the product team. Let’s start with prototyping solutions.

You’ve now worked with the user researcher to elicit user needs, engaged SMEs and stakeholders to understand ‘as is’ processes, identified potential pain points and have a list of stakeholders which you are keeping an eye on and managing (ideally with a communications strategy). While all this was going on, the interaction designer/UX will have (or should have) been working on a prototype to meet some of those user needs (not all of them, this is Agile after all). So where does the BA fit in here then? Well, first of all, as you were involved in eliciting those user needs through your interviews with stakeholders (including users), you want to ensure what the UX is designing meets those needs (and not just something they think is a ‘good idea’. To be fair, UX rarely, if at all, do this). Some BA books will say the BA would create prototypes however, in these days of software development, many organisations now specialise with either a UX, interaction designer or variation (be careful here. I’ve worked with someone who got very irate when I referred to him as a UX when he was an interaction designer!! There is a difference by the way)


Now a prototype’s been developed, you (along with the UR) are taking it out to users to test and get feedback. Again, it’s a skill that you will learn from a good UR. Trying to stop yourself showing a user how to use a prototype is hard……we’re inherently helpful but need to constrain ourselves and see what the user does.

When you feedback the findings from the testing to the rest of the team (a must), you will be asking the developers and QA what possible constraints there may be (if any) if a particular solution was to be implemented. At this stage, you can start engaging the QA to find out how they want the scenarios articulated in the user stories (e.g. are they happy with BDD). This flows nicely in to the next stage.

Evaluate options – High level user stories

For a lot of people, this and the next stage (Define requirements) is where the BA comes in to their own because it’s about user stories. It’s worth pointing out here that if you haven’t begun to understand the rest of the team roles, it makes the last 2 stages a lot more difficult. Remember, you are building relationships and understanding with your team, and the sooner you do this the better it is….for everyone. I’ll come to why a little later.

As the prototype has been tested, some of the design hypotheses will have turned in to proven user needs i.e. the user likes what’s been designed and is ‘good to go’ to be developed in to a ‘thing’. Great, we can at last start writing user stories! I’m not going to cover that subject here as there’s more than enough information out there to cover how to write good user stories. What I will cover here is that you must involve everyone on the team in the creation and elaboration of those stories…. from start to finish. Don’t see the user stories as purely ‘the BA role’. It probably is to write them but they’re actually the whole team’s user stories. There’s nothing more frustrating than spending time and effort creating what you think is the perfect user story only for the front-end developer to say in 3 amigos that the design has changed, or an API has been removed/changed resulting in functionality having to change.

Making the whole team aware of the story, not just the Developers and QA, is a way of managing risks and ensuring the unknowns are kept to a minimum. You’ll never stop all unknowns but you can cut these right down when everyone on the team knows what the story’s about. After all, the BA can’t be expected to think of everything!

Define requirements – User stories

I’ve briefly covered user story development but here is how you take that to the next level and become the linchpin of the development team. One of the most important tools I’ve used on all my Agile teams is the user story map. Jeff Paton has written a great book on the subject (which I’m sure you’ve all read) however, my main issue was getting it implemented. I’ll cover how I overcame this in a later blog but for now, the user story map is not just a tool for displaying user stories. it’s a vehicle for getting the whole team involved keeping the product on track to achieve its aim. As we know, the user story map not only shows a flow of stories from left to right (user journey) but also top to bottom (releases). It gives a short(ish) view of the work of the team but if you add in the designer’s hypothesis board and the product vision, it provides a flow from design right through to development. It’s also a great tool to use at show and tells. It really gets the stakeholders engaged. Much more than a boring set of slides.

I’ve joined many teams where they haven’t had a user story map in place (they’ve normally just got a sprint board) and I find the whole team’s disconnected. The designers are working on something that’s either not part of the product roadmap (if there is one) or they are carrying out user research that developers are building in the next sprint leaving no time for the BA to carry out the analysis of the story. In a nutshell, everyone has a different view of the product’s vision resulting in different priorities and actions. A recipe for disaster.

As Business Analysts in an Agile world, we need to focus on not only building relationships with our stakeholders, but with the team who’s going to develop the product. Not only is this an essential role of the BA, I would argue it’s critical to the success of the team.

One giant leap – from a Business Analyst in the public sector to IT consultant

This blog describes my transition from working as a BA in a large, public sector organization to an IT consultancy, the challenges I faced and some helpful tips if you find your BA career at a bit of a crossroads.

Are you, or have you been in a situation where you feel that your career as a BA is a bit ‘on hold’? Could be that you found yourself on a project where the BA role is misunderstood, so you’re just managing risk logs (for example). Or your service is in Beta with very little product development going on and you’re actually a service manager responding to issues from users?

I was in a similar position and as a civil servant for 14 years, with the last five as a Business Analyst, the decision to move to an IT consultancy was a big one. No, change that, it was huge!

One giant leap….

When I was first approached via a message on LinkedIn, I was apprehensive to say the least. After all, working for the same organization for 14 years puts you in a comfort zone. After a few conversations and weighing up my current situation as a BA, I thought ‘what the hell, it’s worth a look if nothing else’. I felt I had nothing to lose.

One conversation led to another, and within the space of three weeks, I’d left the organization I had been part of for a significant portion of my working life and had become a BA for an IT consultancy. I hadn’t considered moving away from my role in the public sector before but after employing some BA techniques such as SWOT analysis (on myself), evaluating options available to me and risk analysis, I was able to come to a decision I believed would allow me to fulfill my ambitions as a BA.


Do you believe things happen for a reason and that fate plays a part in some of the important events in your life? I certainly do and believe this was one of those very occasions that fate played a big part in my decision. First of all, I was able to speak to people who had not only heard of the consultancy, but had either recently worked for, or were currently employed by them. The biggest single consideration I had was the fact I would be leaving a very secure job for a potentially less secure one. Of course, no one can predict the future, but from the people I spoke to, the company was secure and was growing. A good sign.

Here’s my first tip: If you are approached by a firm, or you are thinking of working for another organization, do your homework on them. After all, you’re a BA right? So employ some of those BA tools and techniques to understand the organization. What is their mission? How important do they view their staff? Do they have a revolving door with high staff turnover? Think about what you want out of your career as a BA and whether that company can help you get there.

Don’t underestimate your skills

One of the questions I had was, ‘am I good enough to be a consultant?’. The big question right? And how do you actually know? You might get feedback from your line manager, but if they’re not a BA, or one with not enough experience and knowledge as you (believe me, this often happens in a grade-based organization), then their appraisal of your performance means very little. If you want meaningful feedback, get it from your scrum team. After all, they will be appraising your performance every sprint. In other words, if they’re not happy with your performance, they will let you know. Working in a scrum team is about open and honest conversations, and that includes if you’re not hitting the mark (and vice versa).

Another thing you can do is carry out a SWOT analysis on yourself. Give yourself an honest appraisal of your skills and where you might need to improve. It will also help you in deciding to whether to move on or not. Here’s my SWOT analysis:

  • Strengths
    • Experience as a Business Analyst
    • Experience working in a scrum team
    • Active in BA Community
  • Weaknesses
    • No recognized BA qualifications
    • Hadn’t worked in private/commercial sector as a BA
    • Had not practiced the full range of BA techniques
  • Opportunities
    • Specialise as a BA
    • Work with Bas from different backgrounds
    • Work in different agile frameworks
  • Threats
    • Job security
    • Downturn in the market for Business Analysts

Carrying out a SWOT analysis allows you articulate what you believe are your strengths and more importantly, what your weaknesses are and can be worked on. It also allows you to evaluate the organization you might be moving to and the risks associated with it. You’ll see I’ve identified only two threats because as far as I was concerned, these were the only things out of my control. I felt that as I had the opportunity to specialize as a BA, I would make sure I was able to build on my strengths and work on my weaknesses. And at the same time maximizing the opportunities.

My next tip: if you are committed to being a great BA, be aware of your weaknesses and work on them to turn them into strengths. And constantly evaluate them. Don’t become a BA who says they have ten years’ experience as a BA when you’ve actually got one years’ experience repeated ten times.

And finally….

If, like me, you find yourself at a bit of a crossroads in your BA career and you’re not sure what to do, don’t settle for the status quo. The only person who loses out is you. Evaluate yourself, get feedback from others and strive to be a better Business Analyst. There’s so much information out there for you to tap in to, so make the most of it.

It’s a rewarding career as a BA and a role that is highly sought after in the business world. Don’t let your current circumstances stop you from being a great BA if that’s what you want to be. If it takes a leap of faith to join a consultancy or another organization, then weigh up your options and go for it. After all, fortune favours the brave.

Top 3 Activities for a Business Analyst in a Discovery Phase

In at the deep end

So, you’ve just heard you’re going to be the Business Analyst on an Agile team that’s going in to a Discovery and it’s your first one.
For my first Discovery, it was daunting let me tell you. I already knew quite a few tools and techniques a BA should use during the lifecycle of a project, but what ones do I use that are particular to a Discovery phase?
For this blog, I interviewed other Business Analysts, Scrum Masters, Product Owners and Developers to get their view on what the role of the BA is in Discovery and I will use their opinions (along with mine) to provide what I think are the top 3 tasks a BA should carry out.

Time is of the essence

You may be thinking, ‘surely you just apply the right tool or technique for the situation?’ Good question and I would say this is true. However. Unlike a traditional project where the BA would investigate, analyse and document literally everything, in Agile, Discovery phases are given quite a short amount of time before moving to Alpha and this is where as a BA (along with the rest of the team), you need to use your time wisely as you just won’t have the time to do all those ‘traditional’ BA activities.

Now, there is a process to follow in that you can’t start to create a backlog until you know what the user and business needs are, and you can’t find out those needs until you identify your users and stakeholders. So, this is where we’ll start.

Stakeholders: Don’t just identify, analyse

The top activity the other roles identified as a key role of the BA was to understand and define the problem. However, before we get to that stage, we need to identify our stakeholders and users. And perhaps more importantly, understand the stakeholder’s interest and their influence in your project.

For me, this is a critical exercise that I don’t feel is given the importance it should at the start of a project. They either get done and are left static throughout the project or not done at all.

While the BA might lead on this activity, it’s most definitely an exercise the whole team need to be part of. My tip here is to put a stakeholder interest/influence matrix on the team wall (hopefully you have one, if not, get some whiteboards!) and give yourself and the team a couple of hours for the session. There are plenty of templates online you can use or if not, just draw it on some flipchart. Give the team around 10-15 minutes to identify who they think are stakeholders and begin to plot them on the matrix.

There may be some conflict where these people sit on the matrix but as long as you agree on who are the highly influential or clearly fit in to a category, the borderline ones you can leave for now.

In terms of analysis and potential time constraints you have, don’t go in to any particular detail and spend time creating stakeholder wheels or stakeholder management plans, the interest/influence grid is sufficient. In addition, use the matrix to create your communication strategy to define what methods you will use to show progress of the Discovery to stakeholders and how often you will communicate with them.

For identifying users, this will be something the User Researcher will lead on as they will be interviewing them but you as the BA should be involved in those sessions. After all, if you are going to be writing the user stories based on their needs, you need to get this first hand. You will also pick up good interview techniques from the UR.

Framing the problem to define scope

Ok, so we now have a list of stakeholders and users and it’s time to start engaging them. Before you start looking at things like defining ‘as is’ processes, pain points and setting up interviews with stakeholders to get this information, you need to have an understanding of what the actual problem is the team has been put together to fix.

You may have been given a mandate as to what the issues are but until you engage the people ‘at the coal face’, they are just perceived issues. The quickest way to get to the root causes is to get those key stakeholders in a workshop and identify the following:

• Why are we doing this work?
• Who are our users, clients and stakeholders?
• What outcomes might users get from this?
• What outcomes might the organisation get from this?
• What are our key metrics?

Now, a lot of information will come out of this session and I see the key role of the BA is to deconstruct all these thoughts and views and turn it into something meaningful……like a problem and a product vision statement.

These statements are short and provide an overview of the vision, problems and methods the team will use to address them. It should be no more than a few sentences which is a difficult task and one I suggest should be collaborated and created with the rest of the team.

Once you are all happy with it, you need to share it with the stakeholders. Not to get agreement or for endless reviews, but to ensure everyone is on board with what the team are trying to achieve.

As some (maybe most) stakeholders may not be aware what a problem and vision statement is, you may have to spend some time explaining its purpose to them. Point out it’s not a personal view, but a collective interpretation of perceived issues that need addressing.

The backlog

As with defining scope, starting a backlog of user stories is not solely the responsibility of the Business Analyst but is something the team are responsible for and should contribute to. That said, the BA does play a critical role in the creation of a backlog. And that is to ensure that what goes in to it is of an acceptable standard. After all, rubbish in, rubbish out right?

I’ve seen this so many times whether it be on a new product or one that has progressed in to Alpha and Beta where the backlog has become a bit of a dumping ground for every idea, whim or ‘wouldn’t it be good if’ thought.

For a start, everything in the backlog should either be related to a user need or part of the product roadmap. If it doesn’t, it shouldn’t be there. If someone does have an idea worth further exploration, put it on the user research/UX hypothesis board so they can establish whether there is an actual need for it.

Before you start creating a backlog, get the team together to agree ground rules. I suggest you hold a user story writing workshop with the team where you can begin outlining the backlog. This ensures the team are involved from the start and you can agree principles with them to stay clear of the ‘bloated backlog’.

Who might I be working with in a Discovery team?

Discovery teams can be made up of several roles, most commonly; a Product Owner, User Researcher, Business Analyst(s), Subject Matter Experts (SMEs) and a Scrum Master/Delivery Manager

I’ve worked on Discoveries where a Scrum Master/Delivery Manager wasn’t part of the initial team and I found the focus and cohesion of the team became lost at times due to a lack of discipline in setting and achieving targets (i.e. sprint planning). When time is the key factor, the team needs to stay focused on its goals which I think the Scrum Master brings.

You’ll start to get the impression now that the Business Analyst is not really ‘solely’ responsible for the outputs of a Discovery but is involved in all of them. One of the people I interviewed for this blog explained his view of the role of the BA in a great way. He said they are ‘decoders’. By this he meant they translate all the information gathered (and there will be a lot of it) in to outputs that not only the team understand, but any stakeholders.

I believe this is the primary role of the BA however in an Agile Discovery, you should be able to evaluate what you are doing is of value and that you’re not just ‘going through the motions’ because of pre-defined duties of the Business Analyst.

I hope this has been helpful and that if you are asked to join a Discovery team, you are equipped to get engaged in those top key deliverables to make the Discovery a success.