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 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 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 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 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 BA plan template.
Now, I've talked about this. This is the idea that you'll clarify when you first start, regardless of what type of project, regardless if it's an agile project. So that agile here means agility of 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 provide clarity to your stakeholders. The sections include the project context, 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. 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 part of your business analysis? 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 we use to do the analysis. It's about what are you going to do? 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 the project 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 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 where to 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 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, maybe you're going to produce requirements, traceability matrix, Maybe you're going to produce stakeholder net starting off 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 outcome that your wider stakeholders are interested in. So the requirements are the user stories, 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 point where they can be turned into test cases, which is the most common use case for ABA. 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 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 engagement area and I don't have a 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.
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.
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 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 for it. But then you've got someone who's ultimately paying for it, the responsible owner. So that senior responsible owner or also known, you know, as your sponsor, 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 things going well. Now they are not the person that you generally are doing business with. 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 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 from a 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, and they want to tell you their opinion. And so you suck up all your time doing that as a junior. And actually that person is just someone who's maybe interesting, but and they may have some valid points too. I'm not dismissing that, but that's not where you should be spending your time when you're a junior. And I think we all get caught up in that.
And the columns you really have again, in Excel spreadsheet, 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?
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 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 you're going to do next and refining the backlog isn't really something that happens in reality 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 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. 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 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 projects start with a solution in mind 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 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 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 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 the pain points and whatnot. 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 since I was, you know, first on the job. But effectively you are mapping up processes. And again, I've got some great podcast episodes on how to do that. BPMN is the is the gold standard for 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 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 doing that, do that lower level and then at the high level draw just normal process flows. I've got a great template that I use. 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 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, 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 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 suggest Excel maybe, but maybe an online tool or even a PowerPoint slide would be really good 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 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, 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're using, and it helps control scope. And this is something that I 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 area that projects file on. And it's really to how do you articulate scope in a way which is very clear and articulate and has 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 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 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 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 story sprints. So it's the transition state between epics and user stories. 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 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
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? 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 traceability matrix where this all comes together. So that's where you're mapping the user storage to the apex and the business objectives. 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 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. 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 template you should have. So that's in your process template. They should be your minimum 2 templates you have in your 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 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
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 have empathy or they're not able to really figure out who their personas are. They're really focused on the service design elements. 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. But that's exactly what we do in a 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 set of them. That's why we have a set of personas. And then you need to understand what the characteristics are. And this is so important because not 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, 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 make sure that and a requirement ideally 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, the different test scenarios can come from your personas 10 is to have a requirements pack of some description. 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.
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 of thinking, 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. 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 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 member once we start that plan.
But the idea is that you should follow the project phases and the most do the most appropriate thing in that phase, right of 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 you have a requirements pack in PowerPoint.
And the reason I do that is that one, 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 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. 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. I'll see you next week.