June 6, 2025 • 27 mins
Templates don’t just make life easier—they make you better.
In this BA Bites episode, I break down the 10 most essential templates every Business Analyst should have in their toolkit. These aren’t fluffy checklists or overengineered frameworks. They’re the practical, real-world templates that help you frame work clearly, communicate with stakeholders, and keep delivery on track.
We’re covering:
Agile BA plans
Stakeholder mapping
Problem statements
BPMN models
Lean canvases
Requirements… all the way through to
The Requirements Pack
If you’ve ever wanted to build a repeatable way of working that delivers value without the chaos, this is the episode for you.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:01):
Is live and die by their tools, but not all templates are
created equal. In this BA Bytes episode, I will
break down 10 essential templates that every BA needs in
their toolkit, regardless of their skill level.
Whether you're contracting or consulting or embedded in a
(00:22):
permanent role, these templates will help you frame,
communicate, and deliver value faster.
It'll allow you to save time, reduce chaos, and start
following some standard Better BA practices.
And to others, you'll start showing up like a senior, even
(00:46):
if you're just starting out. The Better Business Analysis
Institute presence, the Better Business Analysis podcast with.
Welcome back to this BA Bytes episode on the Bit of Business
Analysis podcast. Now, why are templates
(01:11):
underrated? They're they're actually
underrated. I it's easy to find templates.
You can always Google them so they're easy to find, but to
find a decent template that helps you along the way and
connects to another template that connects to another
template, which is all part of your delivery journey, that's
(01:31):
essential. And so I'm going to give you
some templates. They're not theoretical
templates, by the way. They're actual ones I use, and
they're part of the Better Business Analysis framework.
So #1 we start with the Agile BAplan template.
Now, I've talked about this. This is the idea that you'll
(01:52):
clarify when you first start, regardless of what type of
project, regardless if it's an agile project.
So that agile here means agilityof the plan, not necessarily the
project management approach. And this allows you to clarify
your analysis approach from whenever you're dropped into a
project. It allows you to both get and
(02:17):
provide clarity to your stakeholders.
The sections include the projectcontext, so the context of the
project. Write that up in 2 paragraphs.
If you can't summarize what the project's about in two
paragraphs, you need to talk to your project manager and you
need to make that clear. It's not clear to you.
(02:37):
It's not clear to the stakeholders.
What are you reporting up? That's genuinely a good pack,
like a monthly reporting pack for a project manager.
They will have to report and they'll have to do a couple of
lines on the project. What does that say?
What is the scope of your analysis?
What are you going to do as partof your business analysis?
(03:02):
Is it simply to produce requirements, detailed
requirements or just high level requirements?
Are you going to be involved in the delivery phase or not?
So this is more around setting you up for success.
It's not about the tools that weuse to do the analysis.
It's about what are you going todo?
(03:23):
How are you going to do it? Why are you going to do it, and
when are you going to do it? OK, so it talks about the key
artifacts that you're going to produce.
And you agree with this with theproject manager.
So you say these are my steps goes into a project plan.
This is what I plan to do. Does that fit in with the rest?
Yes, it does. Co-op put in project manager
might say, oh, I'll put in 20 hours for you to, you know, do
(03:44):
some workshops. You're like, well, actually this
is kind of let me think about that.
This is the approach I'm going to take and you might take the
lead. If they are more experienced
than you or you don't know whereto start, then maybe you go with
that and go, OK, that's fine. But I want to check in after
I've done a couple of workshops just to see if that's enough
(04:06):
time and agree that that time might need to be pushed out.
And then you can say these are the actual BA artifacts I'm
producing, which we just talked about South actual BA thing.
So what I'm talking about, maybeyou're going to produce
requirements, traceability matrix, Maybe you're going to
(04:29):
produce stakeholder net startingoff with to know who to engage
with if it's a big project. And then deliverables, which
those artifacts I talked about are kind of, if you like
waypoints, they are things you produce which the project
manager you might be interested in, a few people in the project
team might be interested in. The deliverable is almost the
(04:52):
outcome that your wider stakeholders are interested in.
So the requirements are the userstories, what is the
deliverable? And that shows up for the
business here or for another team like the tester producing
the user stories down to a pointwhere they can be turned into
test cases, which is the most common use case for ABA.
(05:16):
And the idea is that this Agile BA plan, it's adaptive for any,
you know, waterfall setup or hybrid and agile.
I can have to keep saying that because I've called it the Agile
BA template. Now, this is simply an Excel
spreadsheet. So it is simply these headings
and an Excel spreadsheet. And I will, if you join our club
(05:41):
in the future, which is launching soon, you'll get a
copy of this template to use which consistently gets updated
and has some examples #2 is the stakeholder map and matrix.
And I have to say I've been Chrissy Lacks on this one
myself. If I'm doing a huge customer
(06:04):
engagement area and I don't havea change manager and usually I'm
in a size of project where I do,they will manage the stake on a
map or work with me on it. And I don't generally own it.
I just help populate it. And it's really got, you know,
what are the, the risky, who's involved what, what kind of
engagement do they need in it? And it kind of sits well there.
(06:25):
And the flip side of that is when I've done things like what
are the rolling out phones, you know, it's one of my first jobs,
VoIP phones. And it was, you know, who needed
what phone, you know, what was their phone number?
It was just a list of users really, and then maybe their
security rights and what they needed to do.
And so that's a type of stakeholder matrix there.
(06:48):
But when I talk about this particular template, I am
talking about understanding the influence and interest that your
stakeholders play in your engagement.
And so I think it's really important if you're not used to
having this in your head. And maybe I'm, I'm good at this,
It's really to understand, OK, I've got a project manager who
(07:11):
is the business owner for this piece of work.
Is there a product owner? Is there a product, you know,
manager? Who's the sponsor, Who's the
business owner is the person who's kind of your person who's
kind of, I guess accountable forit.
But then you've got someone who's ultimately paying for it,
the responsible owner. So that senior responsible owner
(07:34):
or also known, you know, as yoursponsor, as the person paying
for it. And that's generally could be an
executive level or the CEO of your company or maybe someone
external to your company. So that's the sponsor, that's
the person who's putting the money up and has ultimately got
the has to. They want to know red and the
green. They want to know whether or not
(07:54):
things going well. Now they are not the person that
you generally are doing businesswith.
And so the business owner is usually the person in the area
of the business where you're making change.
That's just the top tip there. And it's the reason why this is
important, especially for a junior BA, is that it maps out
(08:15):
which stakeholders are most important and it, and it kind of
avoids a lot of rework. It also avoids getting a whole
lot of feedback for an area froma stakeholder who is not
responsible for that area accountable or even really
contributes that much to it. So the loudest person in the
room, for example, they may not be someone that you need to
spend as much time with. They're talking to you though,
(08:38):
and they want to tell you their opinion.
And so you suck up all your timedoing that as a junior.
And actually that person is justsomeone who's maybe interesting,
but and they may have some validpoints too.
I'm not dismissing that, but that's not where you should be
spending your time when you're ajunior.
And I think we all get caught upin that.
And the columns you really have again, in Excel spreadsheet,
(08:58):
it's just the role kind of the interest level around.
Look at again, rescue is a really good model for that.
Their influence is really important.
Are they influential? Are they someone who's quiet?
Are they someone who doesn't push?
They're someone who just wants it done and you know, what is
their preferred comms. Now, is it something like you
need to meet the first person once a week?
(09:19):
A business owner, for example, when you're a project manager
and especially if you're a junior BA, you might work with a
project manager and you might meet with your business owner
once every couple of weeks or once a month.
And then if you're working with a product owner and you're ABA,
you might meet with them every day stand up situation or more
likely once a week. And I would say in modern day
(09:43):
projects, once a week is generally more than enough.
The, the, the, the levers don't particularly change unless
you're in a high performing product function, you know,
where you're producing features within a limited scope on a
project. The concept of having daily
stand ups, you know, for the purposes of talking about what
(10:05):
you're going to do next and refining the backlog isn't
really something that happens inreality if you're, if you're, if
you're not working on a product like that.
So if you're in a more project space, then once a week is
generally OK because you're actually spending time doing
analysis, spending time running things up.
You're spending most of your time actually engaging with your
(10:27):
end customers who you're going to be providing value to.
And that's the way that the world works #3 which I've talked
about a lot. So I think if you want to this
one, we've kind of nailed, if you like.
And it's the problem state statement canvas, OK.
And we could just call it a problem statement template.
(10:48):
And we use the five WS and the two HS, which is of course from
the level 1 course, which is around, you know, why, when, who
and where. And then we've got the two HS,
which is how and how much. So that 5W2H model is a common
model. I haven't, you know, I didn't
(11:08):
come up with it, but it's a really good one.
And that is an example that keeps the conversation focused,
especially with senior stakeholders and it gets
everyone aligned to what is a problem.
And again, there's so many good episodes on that.
But the final point talking point before we go into #4 here
is that and majority of projectsstart with a solution in mind
(11:33):
and the problem is hidden. So if you're a junior out there,
your job is really to find out what the problem is.
And that should form the statement of that, you know, 2
paragraph project context. We're solving this problem.
Very, it's very common for that not to be the case though.
OK. And that's first piece of value
(11:54):
you can add. The next one of course is the
process model or the BPMN diagram template.
So this is where we show, we visualize how things work or
don't, we map out processes. And that really I think is the
(12:14):
number one difference between what ABA does and anyone else
and Golema process analysts to do all that.
I think that's quite right because during a process diagram
and analyzing it and being able to capture it completely is
actually a different role to down to, you know,
documentation. And it's our superpower because
(12:38):
it allows us to really articulate simply very, very
simple, simple terms, provide clarity to the problem at hand
and really the jobs to be done in order to get whatever outcome
is that customers trying to do in that process.
And that's where you can see thepain points and whatnot.
(12:58):
And that's generally your problem domain.
Well, it is your problem domain.And using that template, I mean,
there are lots of ways you can do it.
You can use draw dot IO if you don't want to spend any money.
Vizio's the tool I've used sinceI was, you know, first on the
job. But effectively you are mapping
(13:19):
up processes. And again, I've got some great
podcast episodes on how to do that.
BPMN is the is the gold standardfor that.
But you can get up to a, you know, 80% kind of BPMN.
It does kind of avoid the point of of going having a kind of a
great looking diagram that doesn't kind of take it to the
(13:40):
extremes. However, that's where they
really we land. If you bring a BPMN diagram to
someone who doesn't really understand what the different
symbols made, generally A stakeholder, then you can spend
too much time actually explaining what it is.
I would suggest if you are doingthat, do that lower level and
(14:01):
then at the high level draw justnormal process flows.
I've got a great template that Iuse.
I've actually, it's part of the toolkit that we provide as part
of membership. And it, it doesn't matter what
it looks like. It really matters what it looks
like. It matters where the words are.
It matters, you know, the iconography, it matters the, the
(14:23):
kind of, yeah, all the templating, how you message it,
the layers you use. It's so important.
And so there's a whole, it's a whole arts to do that well #5 is
the length canvas? I mean, if you use the change
canvas or the business canvas, they're all the same concept,
(14:43):
which is to try and frame up strategy on on one page.
And the lean canvas, which we have talked about many times
before and there's great, great podcasts out there that talk
about it in much more detail than I do.
But it really sets up change initiatives or startups or
working with execs in their language in a very easy to
(15:08):
understand way. And usually this one pager kind
of looks like a reporting 1 pager.
And it could be a lot of reporting one pager, as in it
could articulate what your project is on a page.
And then maybe under that, it could have some status options.
And the, again, the best way to do that, I mean, I wouldn't
(15:29):
suggest Excel maybe, but maybe an online tool or even a
PowerPoint slide would be reallygood as a template here.
It's got different boxes with different labels that mean
different things. And it builds in alignment with
your business model thinking. Again, I'm not going to go into
this huge detail, but I think it's really important to have
(15:50):
one of these in your tool kit that all all three the the lean
canvas for if you're in a startup, but it's still useful
to do for a business and ask simple questions.
And if you can't answer those questions, you know, you really
need to go back to talking to your project manager.
Business model Canvas is an internal looking one and a
change canvas is showing what your change initiative and how,
(16:14):
what that is, what that impact is to your business.
Number six is the high level requirements table.
So this is the priority. Epics links to objectives or
themes, whatever language you'reusing, and it helps control
scope. And this is something that I
(16:35):
harp on about at the Better Business Analysis Institute all
the time. It's probably my number one
piece of advice for a BA Once they understand process
modelling, how to write a user story, then I say, you know that
this area is the number one areathat projects file on.
And it's really to how do you articulate scope in a way which
(16:59):
is very clear and articulate andhas traceability all the way
down to requirements, testing features and whatnot.
And that's your epic level. And it forces early thinking
about feasibility, viability, are there any gaps?
What's the value you're providing?
And it's simply using the same format as the, the story
(17:20):
template format, the user story template, epic ID, you know,
description, a link to an objective, which is so
important, the priority and the acceptance criteria at a very
high level. And if that is locked in,
that's, that is such the most importable, important, sorry
piece of the puzzle that I've added to my toolkit has changed
(17:43):
projects and made them more successful as a result of doing
that. So that's a really, really hot
1. And obviously we have some
templates that we use. You could just use Excel for
that. And it is something you need to
research a little bit #7 you should be a little bit kind of
(18:04):
used to, which is when you're, it's called the Detail
Requirements Catalog. I don't really like the name,
but the idea is that this is where you are translating those
high level epics into user storysprints.
So it's the transition state between epics and user stories.
(18:24):
OK. This is a little bit different
to working in Jira and elaborating user stories.
This is another step that gets doesn't get done well by BAS and
and we have some problems here. So you should really understand
the pieces of the puzzle, the tasks that need to be done in
(18:44):
order to complete the epic at A at a function and functionality
level and non functional level. And that allows you to have some
traceability. It allows you to link to and do
your traceability matrix, which is our next template, but it
also provides clarity in terms of what needs to be done in what
(19:06):
order. So another way of really
articulating this, I think for #7 would be user story map.
OK? I think that's really what we're
trying to achieve here. It's what it drops out of the
epics and what needs to be done and what sequence.
This is your first cut, high level requirements and you use
them best. Are they independent?
(19:26):
Are they negotiable? Are they valuable?
Are they and you estimate them at some degree and estimations
interesting anyway, are they small and are they testable?
And then so that's number seven.And then it drops into #8 which
is the requirements traceabilitymatrix where this all comes
together. So that's where you're mapping
the user storage to the apex andthe business objectives.
(19:47):
OK. And again, that's an Excel
spreadsheet. And it's essential if you're
doing a regulated industry or you're delivering project heavy
stuff. Not so much for for product
here. Now, requirements traceability
matrix is something you do for other people as well as
yourself, of course. But this is where it all lands.
This is one of these artifacts. And that helps new team members
(20:10):
understand the project very fast, understands the level of
abstraction and allows you to link to your processes.
And you can use it to track status all the way through.
So before we had Jira and DevOps, we used requirements
traceability matrix. And we just had statuses on it
and vendor responses and where things were happening.
And you still use requirements Traceability Matrix.
(20:31):
If you're going out for RFP and you're producing requirements,
you're managing it, you do it all in there, which is just an
Excel spreadsheet. And you know, we've got some
really good templates for that. This is probably one O 1, if not
the number one critical templateyou should have.
So that's in your process template.
They should be your minimum 2 templates you have in your
(20:53):
toolkit to start today. If you don't have those.
And the difference here is that when you've done your, what we
call a user story map or a detailed requirements catalog,
this is that's your thinking phase, your visualization.
And then you're dropping everything into your
requirements traceability matrix.
And if you're working in an agile delivery Sprint way, then
(21:18):
this is your starting point. You do this before you enter
into your delivery sprints, OK? And this then gets all the user
stories and all the links ideally get moved across to
JIRA. And then the requirements
traceability matrix becomes locked in those projects #9 is
your persona and empathy map. I think this is really
(21:39):
important. And again, something that BAS
don't do, or they leave the human centered design team to
do, which is amazing because a lot of the human centered
designs teams I meet do not haveempathy or they're not able to
really figure out who their personas are.
They're really focused on the service design elements.
(21:59):
And this is where you are building insights to actually
get used. And this, the personas are so
important because it stops stakeholders providing some
guesswork and just looking white.
This has come from the world of marketing.
It's really understanding that you have a return on investment
for the money spent and you go, oh, that's very dry.
(22:20):
But that's exactly what we do ina project.
We're investing. But in this case, we we deal on
the commodity of value. And you need to understand who
is getting the value out of this.
Not everyone, not everyone in New Zealand, not everyone in
America. What is the people that are
getting the value? You need to find those people
and there'll be, you know, a setof them.
That's why we have a set of personas.
(22:41):
And then you need to understand what the characteristics are.
And this is so important becausenot only can you use this in
user experience testing or your service design initiatives, the
personas themselves provide the different variations for
testing. And what I mean by that is say
you've got a requirement to say,I don't know, it's just a very,
(23:02):
very basic requirement around having a description screen that
explains what your app does and provides, you know, a little bit
of a how to and a kind of get started option, right?
That's, that's the user story. Now, this if you had different
personas and one of your personas was maybe someone who
didn't speak English, then that would provide a test case to
(23:26):
make sure that and a requirementideally that you've got a
multilingual kind of landing page that that allows this
person with this language to have the feature to change it
into their language. And so that's just a really
basic example, which can be turned into a requirement, but
you have more subtle pieces, which is just like, for example,
(23:49):
the different test scenarios cancome from your personas 10 is to
have a requirements pack of somedescription.
Now, these used to be called business requirements documents
and they're Word documents and they're huge.
And that is fine. And I would have some sections
and you might even be given one of those.
(24:09):
This is probably most common that if the BA, there's ABA team
existing and they have some templates, you'll get a little
Word document. You can fill it all in.
It is so restrictive in terms ofthinking, but it might give you
some ideas. You need a context diagram and
might then say, you know, where are your processes, current and
future states, the old way of doing it.
(24:30):
And then I would say, what are your requirements now?
That's all good. It shows you almost a flow.
So what juniors would do is I would start at the start of that
diagram. Sorry, that template, that Word
document and they just start filling out from top to bottom
and that get provide. That was a method.
That's the method for analysis and and I've done that many a
time. That's fine if you're more
(24:52):
comfortable with the delivery journey, which we've talked
about and and go to our website if you're not comfortable with
it and you know, become a memberonce we start that plan.
But the idea is that you should follow the project phases and
the most do the most appropriatething in that phase, right of
(25:16):
that project. So if you're in the early
stages, you should really be finding out what scope is and
doing the high level requirements.
So that's important. And using Word templates, OK.
However, people don't read them.So the problem is they might
read them once. So I would strongly suggest that
(25:37):
you have a requirements pack in PowerPoint.
And the reason I do that is thatone, you can present it.
And yes, people moan about the fact that people still use
PowerPoint. It actually forces you to write
things in a concise and clear way.
And if you can't articulate what's going on in your project
in like 20 slides with everything and all your analysis
(25:59):
along the way, you can use the sections from the Word template
if you want, right? But you can jump around a bit
more and you can present the ones, the slides that you've
got, hide the rest. This is a really, really good
way of doing and constructing business requirements for an
external audience. So that's number 10.
I hope you learned something today.
(26:20):
They are the top essential templates that every BA needs.
We've talked about it before, but it's it's just a reminder
that if you want to get ahead from being a junior or even an
intermediate BA who's plotted around to being a senior, this
is really one of those tangible steps that you can take today to
really make yourself a better BA.
(26:42):
I'll see you next week.
Is live and die by their tools, but not all templates are
created equal. In this BA Bytes episode, I will
break down 10 essential templates that every BA needs in
their toolkit, regardless of their skill level.
Whether you're contracting or consulting or embedded in a
(00:22):
permanent role, these templates will help you frame,
communicate, and deliver value faster.
It'll allow you to save time, reduce chaos, and start
following some standard Better BA practices.
And to others, you'll start showing up like a senior, even
(00:46):
if you're just starting out. The Better Business Analysis
Institute presence, the Better Business Analysis podcast with.
Welcome back to this BA Bytes episode on the Bit of Business
Analysis podcast. Now, why are templates
(01:11):
underrated? They're they're actually
underrated. I it's easy to find templates.
You can always Google them so they're easy to find, but to
find a decent template that helps you along the way and
connects to another template that connects to another
template, which is all part of your delivery journey, that's
(01:31):
essential. And so I'm going to give you
some templates. They're not theoretical
templates, by the way. They're actual ones I use, and
they're part of the Better Business Analysis framework.
So #1 we start with the Agile BAplan template.
Now, I've talked about this. This is the idea that you'll
(01:52):
clarify when you first start, regardless of what type of
project, regardless if it's an agile project.
So that agile here means agilityof the plan, not necessarily the
project management approach. And this allows you to clarify
your analysis approach from whenever you're dropped into a
project. It allows you to both get and
(02:17):
provide clarity to your stakeholders.
The sections include the projectcontext, so the context of the
project. Write that up in 2 paragraphs.
If you can't summarize what the project's about in two
paragraphs, you need to talk to your project manager and you
need to make that clear. It's not clear to you.
(02:37):
It's not clear to the stakeholders.
What are you reporting up? That's genuinely a good pack,
like a monthly reporting pack for a project manager.
They will have to report and they'll have to do a couple of
lines on the project. What does that say?
What is the scope of your analysis?
What are you going to do as partof your business analysis?
(03:02):
Is it simply to produce requirements, detailed
requirements or just high level requirements?
Are you going to be involved in the delivery phase or not?
So this is more around setting you up for success.
It's not about the tools that weuse to do the analysis.
It's about what are you going todo?
(03:23):
How are you going to do it? Why are you going to do it, and
when are you going to do it? OK, so it talks about the key
artifacts that you're going to produce.
And you agree with this with theproject manager.
So you say these are my steps goes into a project plan.
This is what I plan to do. Does that fit in with the rest?
Yes, it does. Co-op put in project manager
might say, oh, I'll put in 20 hours for you to, you know, do
(03:44):
some workshops. You're like, well, actually this
is kind of let me think about that.
This is the approach I'm going to take and you might take the
lead. If they are more experienced
than you or you don't know whereto start, then maybe you go with
that and go, OK, that's fine. But I want to check in after
I've done a couple of workshops just to see if that's enough
(04:06):
time and agree that that time might need to be pushed out.
And then you can say these are the actual BA artifacts I'm
producing, which we just talked about South actual BA thing.
So what I'm talking about, maybeyou're going to produce
requirements, traceability matrix, Maybe you're going to
(04:29):
produce stakeholder net startingoff with to know who to engage
with if it's a big project. And then deliverables, which
those artifacts I talked about are kind of, if you like
waypoints, they are things you produce which the project
manager you might be interested in, a few people in the project
team might be interested in. The deliverable is almost the
(04:52):
outcome that your wider stakeholders are interested in.
So the requirements are the userstories, what is the
deliverable? And that shows up for the
business here or for another team like the tester producing
the user stories down to a pointwhere they can be turned into
test cases, which is the most common use case for ABA.
(05:16):
And the idea is that this Agile BA plan, it's adaptive for any,
you know, waterfall setup or hybrid and agile.
I can have to keep saying that because I've called it the Agile
BA template. Now, this is simply an Excel
spreadsheet. So it is simply these headings
and an Excel spreadsheet. And I will, if you join our club
(05:41):
in the future, which is launching soon, you'll get a
copy of this template to use which consistently gets updated
and has some examples #2 is the stakeholder map and matrix.
And I have to say I've been Chrissy Lacks on this one
myself. If I'm doing a huge customer
(06:04):
engagement area and I don't havea change manager and usually I'm
in a size of project where I do,they will manage the stake on a
map or work with me on it. And I don't generally own it.
I just help populate it. And it's really got, you know,
what are the, the risky, who's involved what, what kind of
engagement do they need in it? And it kind of sits well there.
(06:25):
And the flip side of that is when I've done things like what
are the rolling out phones, you know, it's one of my first jobs,
VoIP phones. And it was, you know, who needed
what phone, you know, what was their phone number?
It was just a list of users really, and then maybe their
security rights and what they needed to do.
And so that's a type of stakeholder matrix there.
(06:48):
But when I talk about this particular template, I am
talking about understanding the influence and interest that your
stakeholders play in your engagement.
And so I think it's really important if you're not used to
having this in your head. And maybe I'm, I'm good at this,
It's really to understand, OK, I've got a project manager who
(07:11):
is the business owner for this piece of work.
Is there a product owner? Is there a product, you know,
manager? Who's the sponsor, Who's the
business owner is the person who's kind of your person who's
kind of, I guess accountable forit.
But then you've got someone who's ultimately paying for it,
the responsible owner. So that senior responsible owner
(07:34):
or also known, you know, as yoursponsor, as the person paying
for it. And that's generally could be an
executive level or the CEO of your company or maybe someone
external to your company. So that's the sponsor, that's
the person who's putting the money up and has ultimately got
the has to. They want to know red and the
green. They want to know whether or not
(07:54):
things going well. Now they are not the person that
you generally are doing businesswith.
And so the business owner is usually the person in the area
of the business where you're making change.
That's just the top tip there. And it's the reason why this is
important, especially for a junior BA, is that it maps out
(08:15):
which stakeholders are most important and it, and it kind of
avoids a lot of rework. It also avoids getting a whole
lot of feedback for an area froma stakeholder who is not
responsible for that area accountable or even really
contributes that much to it. So the loudest person in the
room, for example, they may not be someone that you need to
spend as much time with. They're talking to you though,
(08:38):
and they want to tell you their opinion.
And so you suck up all your timedoing that as a junior.
And actually that person is justsomeone who's maybe interesting,
but and they may have some validpoints too.
I'm not dismissing that, but that's not where you should be
spending your time when you're ajunior.
And I think we all get caught upin that.
And the columns you really have again, in Excel spreadsheet,
(08:58):
it's just the role kind of the interest level around.
Look at again, rescue is a really good model for that.
Their influence is really important.
Are they influential? Are they someone who's quiet?
Are they someone who doesn't push?
They're someone who just wants it done and you know, what is
their preferred comms. Now, is it something like you
need to meet the first person once a week?
(09:19):
A business owner, for example, when you're a project manager
and especially if you're a junior BA, you might work with a
project manager and you might meet with your business owner
once every couple of weeks or once a month.
And then if you're working with a product owner and you're ABA,
you might meet with them every day stand up situation or more
likely once a week. And I would say in modern day
(09:43):
projects, once a week is generally more than enough.
The, the, the, the levers don't particularly change unless
you're in a high performing product function, you know,
where you're producing features within a limited scope on a
project. The concept of having daily
stand ups, you know, for the purposes of talking about what
(10:05):
you're going to do next and refining the backlog isn't
really something that happens inreality if you're, if you're, if
you're not working on a product like that.
So if you're in a more project space, then once a week is
generally OK because you're actually spending time doing
analysis, spending time running things up.
You're spending most of your time actually engaging with your
(10:27):
end customers who you're going to be providing value to.
And that's the way that the world works #3 which I've talked
about a lot. So I think if you want to this
one, we've kind of nailed, if you like.
And it's the problem state statement canvas, OK.
And we could just call it a problem statement template.
(10:48):
And we use the five WS and the two HS, which is of course from
the level 1 course, which is around, you know, why, when, who
and where. And then we've got the two HS,
which is how and how much. So that 5W2H model is a common
model. I haven't, you know, I didn't
(11:08):
come up with it, but it's a really good one.
And that is an example that keeps the conversation focused,
especially with senior stakeholders and it gets
everyone aligned to what is a problem.
And again, there's so many good episodes on that.
But the final point talking point before we go into #4 here
is that and majority of projectsstart with a solution in mind
(11:33):
and the problem is hidden. So if you're a junior out there,
your job is really to find out what the problem is.
And that should form the statement of that, you know, 2
paragraph project context. We're solving this problem.
Very, it's very common for that not to be the case though.
OK. And that's first piece of value
(11:54):
you can add. The next one of course is the
process model or the BPMN diagram template.
So this is where we show, we visualize how things work or
don't, we map out processes. And that really I think is the
(12:14):
number one difference between what ABA does and anyone else
and Golema process analysts to do all that.
I think that's quite right because during a process diagram
and analyzing it and being able to capture it completely is
actually a different role to down to, you know,
documentation. And it's our superpower because
(12:38):
it allows us to really articulate simply very, very
simple, simple terms, provide clarity to the problem at hand
and really the jobs to be done in order to get whatever outcome
is that customers trying to do in that process.
And that's where you can see thepain points and whatnot.
(12:58):
And that's generally your problem domain.
Well, it is your problem domain.And using that template, I mean,
there are lots of ways you can do it.
You can use draw dot IO if you don't want to spend any money.
Vizio's the tool I've used sinceI was, you know, first on the
job. But effectively you are mapping
(13:19):
up processes. And again, I've got some great
podcast episodes on how to do that.
BPMN is the is the gold standardfor that.
But you can get up to a, you know, 80% kind of BPMN.
It does kind of avoid the point of of going having a kind of a
great looking diagram that doesn't kind of take it to the
(13:40):
extremes. However, that's where they
really we land. If you bring a BPMN diagram to
someone who doesn't really understand what the different
symbols made, generally A stakeholder, then you can spend
too much time actually explaining what it is.
I would suggest if you are doingthat, do that lower level and
(14:01):
then at the high level draw justnormal process flows.
I've got a great template that Iuse.
I've actually, it's part of the toolkit that we provide as part
of membership. And it, it doesn't matter what
it looks like. It really matters what it looks
like. It matters where the words are.
It matters, you know, the iconography, it matters the, the
(14:23):
kind of, yeah, all the templating, how you message it,
the layers you use. It's so important.
And so there's a whole, it's a whole arts to do that well #5 is
the length canvas? I mean, if you use the change
canvas or the business canvas, they're all the same concept,
(14:43):
which is to try and frame up strategy on on one page.
And the lean canvas, which we have talked about many times
before and there's great, great podcasts out there that talk
about it in much more detail than I do.
But it really sets up change initiatives or startups or
working with execs in their language in a very easy to
(15:08):
understand way. And usually this one pager kind
of looks like a reporting 1 pager.
And it could be a lot of reporting one pager, as in it
could articulate what your project is on a page.
And then maybe under that, it could have some status options.
And the, again, the best way to do that, I mean, I wouldn't
(15:29):
suggest Excel maybe, but maybe an online tool or even a
PowerPoint slide would be reallygood as a template here.
It's got different boxes with different labels that mean
different things. And it builds in alignment with
your business model thinking. Again, I'm not going to go into
this huge detail, but I think it's really important to have
(15:50):
one of these in your tool kit that all all three the the lean
canvas for if you're in a startup, but it's still useful
to do for a business and ask simple questions.
And if you can't answer those questions, you know, you really
need to go back to talking to your project manager.
Business model Canvas is an internal looking one and a
change canvas is showing what your change initiative and how,
(16:14):
what that is, what that impact is to your business.
Number six is the high level requirements table.
So this is the priority. Epics links to objectives or
themes, whatever language you'reusing, and it helps control
scope. And this is something that I
(16:35):
harp on about at the Better Business Analysis Institute all
the time. It's probably my number one
piece of advice for a BA Once they understand process
modelling, how to write a user story, then I say, you know that
this area is the number one areathat projects file on.
And it's really to how do you articulate scope in a way which
(16:59):
is very clear and articulate andhas traceability all the way
down to requirements, testing features and whatnot.
And that's your epic level. And it forces early thinking
about feasibility, viability, are there any gaps?
What's the value you're providing?
And it's simply using the same format as the, the story
(17:20):
template format, the user story template, epic ID, you know,
description, a link to an objective, which is so
important, the priority and the acceptance criteria at a very
high level. And if that is locked in,
that's, that is such the most importable, important, sorry
piece of the puzzle that I've added to my toolkit has changed
(17:43):
projects and made them more successful as a result of doing
that. So that's a really, really hot
1. And obviously we have some
templates that we use. You could just use Excel for
that. And it is something you need to
research a little bit #7 you should be a little bit kind of
(18:04):
used to, which is when you're, it's called the Detail
Requirements Catalog. I don't really like the name,
but the idea is that this is where you are translating those
high level epics into user storysprints.
So it's the transition state between epics and user stories.
(18:24):
OK. This is a little bit different
to working in Jira and elaborating user stories.
This is another step that gets doesn't get done well by BAS and
and we have some problems here. So you should really understand
the pieces of the puzzle, the tasks that need to be done in
(18:44):
order to complete the epic at A at a function and functionality
level and non functional level. And that allows you to have some
traceability. It allows you to link to and do
your traceability matrix, which is our next template, but it
also provides clarity in terms of what needs to be done in what
(19:06):
order. So another way of really
articulating this, I think for #7 would be user story map.
OK? I think that's really what we're
trying to achieve here. It's what it drops out of the
epics and what needs to be done and what sequence.
This is your first cut, high level requirements and you use
them best. Are they independent?
(19:26):
Are they negotiable? Are they valuable?
Are they and you estimate them at some degree and estimations
interesting anyway, are they small and are they testable?
And then so that's number seven.And then it drops into #8 which
is the requirements traceabilitymatrix where this all comes
together. So that's where you're mapping
the user storage to the apex andthe business objectives.
(19:47):
OK. And again, that's an Excel
spreadsheet. And it's essential if you're
doing a regulated industry or you're delivering project heavy
stuff. Not so much for for product
here. Now, requirements traceability
matrix is something you do for other people as well as
yourself, of course. But this is where it all lands.
This is one of these artifacts. And that helps new team members
(20:10):
understand the project very fast, understands the level of
abstraction and allows you to link to your processes.
And you can use it to track status all the way through.
So before we had Jira and DevOps, we used requirements
traceability matrix. And we just had statuses on it
and vendor responses and where things were happening.
And you still use requirements Traceability Matrix.
(20:31):
If you're going out for RFP and you're producing requirements,
you're managing it, you do it all in there, which is just an
Excel spreadsheet. And you know, we've got some
really good templates for that. This is probably one O 1, if not
the number one critical templateyou should have.
So that's in your process template.
They should be your minimum 2 templates you have in your
(20:53):
toolkit to start today. If you don't have those.
And the difference here is that when you've done your, what we
call a user story map or a detailed requirements catalog,
this is that's your thinking phase, your visualization.
And then you're dropping everything into your
requirements traceability matrix.
And if you're working in an agile delivery Sprint way, then
(21:18):
this is your starting point. You do this before you enter
into your delivery sprints, OK? And this then gets all the user
stories and all the links ideally get moved across to
JIRA. And then the requirements
traceability matrix becomes locked in those projects #9 is
your persona and empathy map. I think this is really
(21:39):
important. And again, something that BAS
don't do, or they leave the human centered design team to
do, which is amazing because a lot of the human centered
designs teams I meet do not haveempathy or they're not able to
really figure out who their personas are.
They're really focused on the service design elements.
(21:59):
And this is where you are building insights to actually
get used. And this, the personas are so
important because it stops stakeholders providing some
guesswork and just looking white.
This has come from the world of marketing.
It's really understanding that you have a return on investment
for the money spent and you go, oh, that's very dry.
(22:20):
But that's exactly what we do ina project.
We're investing. But in this case, we we deal on
the commodity of value. And you need to understand who
is getting the value out of this.
Not everyone, not everyone in New Zealand, not everyone in
America. What is the people that are
getting the value? You need to find those people
and there'll be, you know, a setof them.
That's why we have a set of personas.
(22:41):
And then you need to understand what the characteristics are.
And this is so important becausenot only can you use this in
user experience testing or your service design initiatives, the
personas themselves provide the different variations for
testing. And what I mean by that is say
you've got a requirement to say,I don't know, it's just a very,
(23:02):
very basic requirement around having a description screen that
explains what your app does and provides, you know, a little bit
of a how to and a kind of get started option, right?
That's, that's the user story. Now, this if you had different
personas and one of your personas was maybe someone who
didn't speak English, then that would provide a test case to
(23:26):
make sure that and a requirementideally that you've got a
multilingual kind of landing page that that allows this
person with this language to have the feature to change it
into their language. And so that's just a really
basic example, which can be turned into a requirement, but
you have more subtle pieces, which is just like, for example,
(23:49):
the different test scenarios cancome from your personas 10 is to
have a requirements pack of somedescription.
Now, these used to be called business requirements documents
and they're Word documents and they're huge.
And that is fine. And I would have some sections
and you might even be given one of those.
(24:09):
This is probably most common that if the BA, there's ABA team
existing and they have some templates, you'll get a little
Word document. You can fill it all in.
It is so restrictive in terms ofthinking, but it might give you
some ideas. You need a context diagram and
might then say, you know, where are your processes, current and
future states, the old way of doing it.
(24:30):
And then I would say, what are your requirements now?
That's all good. It shows you almost a flow.
So what juniors would do is I would start at the start of that
diagram. Sorry, that template, that Word
document and they just start filling out from top to bottom
and that get provide. That was a method.
That's the method for analysis and and I've done that many a
time. That's fine if you're more
(24:52):
comfortable with the delivery journey, which we've talked
about and and go to our website if you're not comfortable with
it and you know, become a memberonce we start that plan.
But the idea is that you should follow the project phases and
the most do the most appropriatething in that phase, right of
(25:16):
that project. So if you're in the early
stages, you should really be finding out what scope is and
doing the high level requirements.
So that's important. And using Word templates, OK.
However, people don't read them.So the problem is they might
read them once. So I would strongly suggest that
(25:37):
you have a requirements pack in PowerPoint.
And the reason I do that is thatone, you can present it.
And yes, people moan about the fact that people still use
PowerPoint. It actually forces you to write
things in a concise and clear way.
And if you can't articulate what's going on in your project
in like 20 slides with everything and all your analysis
(25:59):
along the way, you can use the sections from the Word template
if you want, right? But you can jump around a bit
more and you can present the ones, the slides that you've
got, hide the rest. This is a really, really good
way of doing and constructing business requirements for an
external audience. So that's number 10.
I hope you learned something today.
(26:20):
They are the top essential templates that every BA needs.
We've talked about it before, but it's it's just a reminder
that if you want to get ahead from being a junior or even an
intermediate BA who's plotted around to being a senior, this
is really one of those tangible steps that you can take today to
really make yourself a better BA.
(26:42):
I'll see you next week.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Las Culturistas with Matt Rogers and Bowen Yang
Ding dong! Join your culture consultants, Matt Rogers and Bowen Yang, on an unforgettable journey into the beating heart of CULTURE. Alongside sizzling special guests, they GET INTO the hottest pop-culture moments of the day and the formative cultural experiences that turned them into Culturistas. Produced by the Big Money Players Network and iHeartRadio.