Bring back business analysis with Howard Podeswa

Join Murray Robinson and Shane Gibson as they dive into the world of agile business analysis with guest Howard Podeswa.

In this episode, we’ll uncover:

🔸 The role and value of a business analyst

🔸 Why big requirements upfront may not be the best approach

🔸 The method of conducting business analysis in an agile way

🔸 How to create use cases and user story maps and break them down into user stories

🔸 The dynamic relationship between the business analyst and the product owner

It’s time to put a spotlight on the critical skill of business analysis, which is key to understanding and prioritising work in every development team. Tune in to learn more!

Read along you will

Murray: In this episode, we talk to Howard Podeswa about agile business analysis. What do business analysts do. What’s its value. Why are big requirements up front, a bad idea. And how do we do business analysis in an agile way? How do we do use cases and user story maps and how do we break them down into user stories? What’s the relationship with the product owner. Business analysis is a critical skill that every development team needs to understand and prioritize their work it’s time to bring back business analysis.

Shane: Welcome to the Nonsense Agile Podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson.

Howard: And I’m Howard Podeswa.

Murray: Hi Howard. Thanks for coming on today. We want to talk to you about agile business analysis . Why don’t you kick us off by telling us about who you are and what your background and experience is. 

Howard: Sure. The mixture of agile business analysis is something that I have been doing, since the nineties when both agile and business analysis came to the fore. I started out on the techie side. In fact I was actually trained as a chemical engineer with a specialty in nuclear engineering. My first job was with Atomic Energy of Canada. I wasn’t meant to actually go into IT at all. I took just one programming course. But my first job with Atomic Energy was working on a simulation program to determine what would happen in the case of a nuclear accident. And I really found the programming aspect of that much more interesting to me than the heat and mass transfer calculations that were also part of all of that.

And so that’s what actually got me into programming. Initially it was a lot of technical stuff. I worked on the first CICs system done in Cobol. It was one of the first interactive applications using mainframe. So it was really very exciting stuff to work on. Very groundbreaking. I’ve done a lot of those kinds of things. Worked on writing an intranet package from scratch to get many computers to talk to each other. Food testing, various applications like that. When business analysis came about in the nineties, I got very interested because I found that I was often frustrated on the development side when I didn’t know the answers.

You might hit it as a developer when you’re designing tables, for example, and you don’t know, whether it’s a one to many relationship or a one-to-one relationship. And you realize, there was some really basic questions that somebody could have asked.

It really occurred to me back then that if we could take the tools and models and techniques that were used on the architecture and systems analysis side, and use them from the perspective of understanding the actual business itself. That we would actually save a lot of time due to misunderstandings and mistakes. These are powerful tools that were being introduced too late into the life cycle. So the moment I saw BA coming out as a job role, I got very interested in it.

One of the first jobs I had was to actually coach bell Canada teams in the use of business analysis techniques within the context of iterative incremental developments, this was in the nineties when, large companies bell is a telecom company.

If they were gonna try to do anything agile, they would use something like RUP the Rational Unified process, which was a little bit easier on them than something like xp Extreme Programming. So I started to specialize in helping companies figure out that piece. How do we do the analysis piece when we are doing agile development, when, the development is iterative and incremental where we don’t actually gather all the requirements upfront, but we gather them and discover them piece by piece a little bit at a time as we go.

There was a lot of guidance to the technical people about how they did their part of the job, but this aspect, this piece of the puzzle was not very well understood. So I worked with various companies on this part of it. A lot of them were banks initially. Like the Canadian Imperial Bank of Commerce, that’s C I B C. I’ve done work for Scotia Bank. Telus, another telecom company, which was the first company that actually came to me and said, we are going agile all in. Not just a few groups here and there. Around 2013 is when my clients were starting to go all in on it. 

I was hearing from them that the developers just talked directly to the customer and nobody writes anything down. So it looks to me like there should be nothing for the BAS to do. What should I do with my business analysts? This is the question that I was getting. I told ’em at the time that the work that those bas were doing is never going to go away. The need for somebody to really understand the business problem and be able to explain to developers is something that’s still gonna be important. And the techniques that are used to understand business rules and understand stakeholders still gonna be important. They’re gonna be done a different way, but you’re still gonna need them. And I think that’s still true today. Business analysis is still being done today. Whether or not the role is called a business analyst though is something else.

In my experience the companies that used to have business analysts, when they’ve transitioned to Agile have not gotten rid of their bas. Sometimes they’ve told the teams, it’s up to you. You decide if you want to put some bas in there. Sometimes the teams have responded by say, we’ll throw some bas in and see what happens. In every case, they’ve actually proved their value and they’ve decided they’re better off with business analysts than they are without them. Now, to me, I don’t really care if you call that person a ba, you call that person a product owner. As long as there’s somebody who actually understands the competency, and knows how to do it and do it well. But I am finding in general that bas haven’t gone away. 

Now where you don’t see them though are in small startup companies which, have other roles that do something similar. Even there though, once those companies mature, we’re starting to find that they’re bringing back either the competency or the actual role itself. 

Murray: Do you find that requirements are being done better in agile teams than they were in the traditional, phase gated waterfall projects? 

Howard: Well, what do you mean by better? Let’s say you replace an existing application, and the only thing that’s wrong with your existing application is the technology’s out of date and you need new technology. Your requirements are quite well known. In a circumstance like that there’s very little uncertainty. If you are purchasing a new system it’s a huge, financial risk if you actually get the requirements wrong, and end up buying the wrong product. 

So in a situation like that, you’re much better off, in my view, to do a very thorough requirements analysis upfront. So I’d say in a situation like that, no, I don’t think Agile will give you a better result.

On the other hand if you are in a situation where there’s uncertainty about the requirements, you’re way better off doing it in an agile way because you don’t really know in the beginning which of the features that you’re thinking about are gonna actually be the most valuable until you get into it.

And so if you end up figuring out in theory what all your requirements are going to be upfront, you may find out that a good chunk of those are actually not gonna be useful or valuable, and that you’ve actually wasted a lot of your time, in doing that. And so you’re much better off doing a little bit at a time, testing it out with your customer base. Taking measurements so that you’re actually data informed and letting that drive the development. The approach that we advocate these days is hypothesis testing. Think about the features that you’re considering as a hypothesis. You hypothesize if they actually have value, and then design a little test to show that they do have value.

Murray: Yep. Couple of things there. I became a BA in the nineties and did it for 12 years before moving into, project management and product management. First thing was there was no training at all. It was a job that you got because you were smart and, analytical and you could talk to people. And you’d be given a document template told go and fill this out. It would have, things like project name objectives, users, functional requirements, non-functional requirements all that sort of stuff.

Howard: I got into the writing business, Murray because of that exact problem. I was coaching a group of social workers and they were about to become business analysts because they were experts on the system that was being developed. They figured they may as well turn them into bas. They came for a QA course to get some training in qa, and I found out quickly that they needed a lot more and realized that training was really inadequate in this area. 

Shane: Do you find that happens a lot still that people confuse subject matter expertise with the skills and competency required to understand business process and analyze it? 

Howard: Think of it like this. Could you explain to somebody how to tie an neck tie? You can do it, you’re great at it. But if you had to actually explain what you do to somebody else, you may have some problem there. Now, this is the position that every user is when they’re trying to explain what they do to developers in a way that the developers, will not misunderstand what they’re talking about.

It takes a certain type of person who is really good at analyzing all those little decisions that you often do unconsciously to explain to developers. So there’s lots of tricks and techniques that business analysts have learned over time to be able to do things like that. Things like business rules analysis and using things like decision tables. These are little tricks that take complicated problems and turn them into a series of very simple problems.

Murray: Yeah I see it as being a translator between the developers and the users. 

Howard: But it’s almost more than that because you’re sometimes even translating it to the users themselves. You’re a little bit like a psychoanalyst. There are things that you do unconsciously. You have unconscious needs and desires that are motivating you but you can’t necessarily articulate them. And with the help of an analyst, you can bring that into consciousness and so that you can explain it to somebody else.

Murray: Yeah, that’s true. There’s a lot of mapping out of stuff. First we do this and then we do that, and then the other thing, and you’re drawing circles on whiteboards with arrows going between them. 

Howard: So, you know, I kept a record of all the kinds of questions that people were asking me as I was coaching them. From that I wrote a book U M L for the IT business Analyst. It was an attempt to take the unified modeling language, which was actually driven by use cases and apply it to the business analysis side. And, since then I’ve been working with lab course STAT Oil, Covance food and Drug Administration. It’s a pretty broad array. And these are all organizations that are doing some combination of business analysis and agile.

Shane: Do you see UML diagrams being used a lot in Agile teams anymore? Because I don’t. 

Howard: I’d like to see them being used more, but no not that much.

Shane: It’s kinda been replaced by the user story. They’ve replaced a diagram with a bunch of words.

Howard: There is diagramming going on, but not so much the U m l diagramming. Use case diagrams. Yes, I am seeing that in places where people are still using use cases. It’s a very simple diagram, so I don’t even know why people consider that to be, extra overhead. It really isn’t. It’s a two second thing with stick figures and an oval for God’s sakes. Is not really very much. The class diagrams, which were a really heavy part of my U M L book are not being heavily used at the business analysis side to understand the business problem. I wish they were more.

There’s a misconception that they’re technical diagrams and therefore should not be used to understand the business and should not be used by non-business people. Oh, by the way, I just wanna go back to another question though that, that you mentioned, Shane, about taking subject matter experts as business analysts and making that confusion.

I just wanted to say I don’t think they’re the same thing, but I do think the following is very important and it’s actually why I’ve always advocated for business analysis as a role. I find that the best organizations have about a 50 50 mix of bas who came from the technical side and learned the business side and the other 50% are people who actually came from the business side and learned the BA part. In order to round themselves out. 

When I started as a systems analyst, it wasn’t my job to speak to the users. So this is actually how it used to be for me back in the old days. The trouble with that is that in order to do that job, you had to be somebody who had really high technical competencies as well as very high people skills. And those analytical competencies that have to do with business analysis.

It was very rare to find those in one person. And I don’t think that you should have to. Some of the best programmers that I’ve seen in my life have horrible people skills. I would not fire them. I would keep them on because they’re worth a hundred programmers. It’s one of them. If you’re going to require that person to also be a people person, that’s gonna be a problem. At the same time, you have all these great people who actually understand the business, who do have core analytical abilities that can be developed and so they make great bas. So I like the mix. I like having a mix of both of those kinds As bas

Shane: Yeah. I agree. I’m a great fan of T-shaped people and talking about skills, not roles. If we look at a matrix, we typically have on the left hand side facilitation analysis type skills. In the middle we typically have engineering development system skills. And on the right we have the kind of wash up, release. Documentation. If you think about that matrix and people skills being strong, when they go down the page, flip it on its side, we’ll often see, T shapes, we sometimes see C shapes . And then we get the nirvana e shape.

Murray: I’m wondering what you think a systems analyst is. 

Howard: In my day it was an architecture job you’d be working out the architecture of the system, working out what all the pieces are and how they spoke to each other, and all the way down to writing detailed technical specifications for the various modules, and then the programmers would write to spec, they’d write the pieces. That’s how it used to be. 

Murray: I have done both of these roles and the systems analysis side of, it seems to me where you create class diagrams and you say you need to have this table and they have a mini to one and so on. But I would go as far as that, I would never go as far as saying that we need to use this systems architecture pattern or component cuz I wasn’t that technical. 

Howard: I’ve got as far as saying I need a routine passes these parameters and here’s the logic and you write it for me. 

Murray: Yeah I would occasionally do that too. So I guess that’s systems analysis. I think these days , you would normally have a technical leader or somebody in the team who would take it to that next level. 

Howard: So yeah, I’m not finding class diagrams being used for conceptual modeling, although I think they should be. I think they’re brilliant. I’ve seen amazing requirements mistakes either made or fixed because of doing that. I’ll give you a very simple example. I was speaking to a group who worked for the government was talking about this very topic and I said, so let’s just discuss as an example a system that you’ve just been working on.

All right, it’s an HR system. All right. So tell me a little bit about it. We start talking, they’ve gotta keep track of unions and union members and, the employees who belong to unions and said, oh, okay. All right. So you just mentioned a union and you mentioned employee to me. So let me just draw a little box here. How many employees per union, how many unions per employee? That’s a question you would ask very quickly using that method. They started to get very embarrassed by this question. I said, why are you embarrassed? It’s funny you should ask this question because we just bought the system. And the one thing the system doesn’t do is it assumes that every employee can only belong to one union. And in fact, we have employees who belong to multiple unions and it’s costing us a fortune now to fix the database. If they just asked a simple question before they had committed themselves to the system, they would’ve saved themselves, lots of time and money.

Shane: In the product world we See a pattern around wire framing, around prototyping and tools like Figma where we draw the screens first to get some feedback about whether they’re gonna meet our needs, and those diagrams you talk about are just the same pattern. We drawing some pictures to see whether we understand the problem, whether there’s some weird use case in there that we’ve never seen before that’s gonna bite our bum to use it as a language where we can look at it and go, yep, that’s what we mean. 

Howard: It even helps you understand the business language itself. I was dealing with a group of people doing a project for Portugal Telecom number years ago, and they kept talking about blah, blah, blah product group. This word product group kept coming up. And the way that they used the term, I’d assume that they meant when they sell you your telephone number. And then along with that, you get call, answer and various other things. And that whole package is the product group. So I just asked the stakeholders how many people understand product group that way?

About half the people put up their hand and half the group put up their hand and said, no, it’s something else entirely. It’s got nothing to do with the way we market it. It’s just your particular line and all the services you have attached to your line, regardless of how it was marketed. That’s the product group.

And it came about when I started to do this many to many question, how many groups per person? This per that. And oh my goodness, we could have gone on for who knows how long, talking about product groups and having no idea what this business concept really means.

I did it with the government when they were doing a project to consolidate payables. The, what they owe citizens and what citizens owe them and to make sure that they’re not, giving citizens money when they actually owe them money because of, fines or whatever. And there were all sorts of financial terms in there that I didn’t understand, but it was through modeling that I actually got a precise understanding of what all those things were. So I think it’s a very, very powerful tool for understanding business rules, for understanding concepts and making sure everybody understands it in the same way.

And you end up with a diagram that you can give to a developer. And even though it’s a conceptual model, it’s actually pretty darn close to what the data model should look like. So you’re handing it to them on a silver platter. I’ve always found that once I explained to teams that this type of model being drawn by a BA is not meant to tell them how to design the data tables, it’s a conceptual model. They relaxed and we were able to get it through. But I can’t talk to every team on the planet to make this case. So anyway, that’s my case for that. But I should say that other types of diagrams like activity diagrams are part of the U M L, they did not become popular. However, business process models, have become popular and agile or not, they’re still remain popular.

As a matter of fact, the first step in building a story map would be, to either do some sort of value stream mapping or to do a business process model. And that’s how you actually determine what that map is even gonna look like. So I think it’s still quite valuable.

Murray: Yeah, so we’ve ended up talking about what are the skills of business analysis, whether you call that person a BA or not, what are the skills? And so far, we’ve talked about understanding the business, understanding the technical people. A lot of facilitation, elicitation skills. Helping the users to understand what they’re talking about, what it is, helping to define key terms and key concepts. Helping to define business rules. Mapping out business processes, defining what they should be in actual maps. Quite a lot of mapping, like class diagrams and so on. And then there’s usually a ton of text that goes with it as some sort of explanation. And I remember I was doing this in the old days, I would be given three months to produce a business requirements document, eight weeks to write it, and it’d be about 80 to a hundred pages. And then they’d go through a four week iterative review. 

Howard: That’s not happening now that’s not happening in an agile context. The way it’s now being done, it’s quite different. In other words first of all, you remember lots and lots of texts. I’m not saying we don’t have to write anymore. That’s totally not true. People misunderstand the Agile Manifesto. It’s obviously more important to get working software out than it is to get documentation out, but that doesn’t mean there’s no value to documentation. Documentation has great value. Primarily for an agile context the value is the next time you go to fix that system. The understanding about that system is there and you know what to build on. There isn’t as much need to write everything down as there was in the past. And part of it has to do with the time factor. In the past when we wrote everything down, when you did it Murray, back in the day, you’d write all that down, but by the time somebody would actually get to coding it, there would be quite a time lag between those two points.

Murray: Yep. 

Howard: In an agile environment, that’s not the case. When you find out some detailed, requirement the time lag for that, actually getting coded is quite small. In the sprint beforehand you clarified some requirements maybe a week before the sprint began, and then the sprint starts and people are coding it already.

So it’s already in your mind. And so there’s not as much need to get absolutely everything down. Secondly, if we’re working in an agile manner, we want to leave flexibility for the requirements to change. And one of the reasons we were so specific in the old days, cause I used to always tell my clients that if you don’t write it down, they’re gonna tell you it wasn’t part of the contract. It’ll get done alright, you just pay extra for it. It wasn’t in the specs right. So you write it down. There’s be no argument, right? 

Murray: We would say that to people and then your stakeholders would tell you everything that they ever imagined that could go into the system because it was their one opportunity to get something done. The next time would be, six or seven years later when the system was redone. So they would tell you everything that they possibly imagined and then you’d go through this Moscow prioritization method and they’d say 80% was mandatory. And so you always ended up with something which was really very gold plated. 

Howard: Absolutely. The beauty of it now is that I can replace a lot of those arguments with sequencing arguments. Instead of saying, is this a must have or a should have, I just say, should we do this first or should we do this second? We have to solve a practical problem. We’re doing iterative development. A little bit of a time is gonna come online. What sequence would you like us to do that in? And suddenly we’re solving a problem together.

Murray: The other problem we had was, I was probably about 70% right with the requirements and about 30% wrong. I don’t mean that somebody would tell me something, I’d write it down wrong. I mean that we as an organization was simply wrong about what was required. We’d quite often miss something quite important which we would discover during development or a whole lot of things would get descoped. That was very common. A lot of things in requirements would just get cut out cuz you were running over budget. 

When I’m talking to people who are still doing this, I say, look, it’s good to have all this context and background and everything for the development team, but you just gotta assume that you’re gonna find during development and testing that a reasonable amount of it is wrong. So you’re wasting a lot of time and effort by writing it all down upfront cause a fair bit of it’s gonna change. 

Howard: Exactly. So now that’s why basically the two principles are you do the least amount of writing that you can get away with without causing harm, and you wait till the last responsible moment, to do anything, including analyzing the requirements for a feature. If you’re looking at a story and you’re using a two week sprint and somewhere around about halfway into the previous sprint, you’re looking ahead, down the product backlog at, the upcoming stories that are likely to get done on the next sprint, and you’re starting to analyze them and you’re not preanalyzing too much, before that. And in terms of larger features a feature, could be something that might take up to even three months, to get done. About halfway into the previous release cycle, you’re starting to look at those features and starting to consider them and starting to, look at breaking some of them up into some of the first stories that you’re gonna be developing.

Murray: Let me talk through some of the problems I’ve seen with Agile teams doing business analysis. One is that there’s no ba. The assumption is that the product owner is gonna do that role, generally speaking, 

Howard: Big problem.

Murray: And they’ve never done it before frequently. People don’t know how to do it. It’s not even recognized that it needs to be done, except as, write me some Jira stories 

Howard: And you know why that’s happened? it’s because of a book called Agile Software Development with Scrum, written by Ken schwaber and mike Beetle. The only reference to requirements, analysis of any kind. In this book is on one page where he says people do too much of it. So it’s almost as though a product backlog just is born filled with all these product backlog items. 

Murray: Yeah so first of all, a lot of people don’t do it and then they run into a lot of problems cuz they’re not doing any analysis. The second thing I see a lot of Howard is a great deal of confusion amongst the developers and even with the product owners. Cause they’re not doing the bigger picture context that they’re working within. Everything is very bitsy. They do a backlog, but then everything gets turned into user stories. And a user story is frequently very small. And the context that the user is in it is forgotten about.

Howard: that is why I like the use cases with user stories.

Murray: Yeah.

Howard: There are many ways to handle this problem, by the way. But what you’re getting down to is this. User stories is a very good structure for the development process while we are developing but it does not provide context. So it’s not a good way, to store your documentation. It’s much to itsy bitsy as you put it. When you take this itsy bitsy approach you have a backlog with a whole bunch of little things where it’s not really clear what the connection is between them. And so one of the things that a business analyst brings to the table is structuring of the backlog. In other words a large request might be I want to be able to do something I wasn’t able to do before.

For example, maybe we’re gonna automate insurance applications so a person can go to a site and do it all by themselves. So that’s really great. But that’s a big job in the backlog. So maybe we’ll call this a feature or if it’s really big, we might call it an epic if it’s even bigger.

And then at some point in time as that feature starts to come up in the backlog and we’re getting close to the point of actually having to work on it, we’re start breaking up that feature into something smaller. And those smaller things are gonna be the stories. And so now you have a structure of epics to features, to stories where we can make a connection, oh, this little thing is part of the bigger thing.

For example, if I say in a story that, as a user, I want to be able to specify, alternative address. Where’s the context? Is this while I’m shopping? Is this, while I’m updating my profile? What am I in the midst of doing? And the beauty of a use case is that you’re always attaching this request to a usage scenario, some actual use user task 

Murray: Tell us what you mean by a use case. 

Howard: So a use case is a fancy word for a usage. So a usage of the product or a usage of the system. They can be at any level. But when I say it without qualifying it, and if I’m talking about a software product, then I’m talking about a chunk of work that a user would wanna do in one session with that computer system or with that product. Some kind of goal that they would be able to achieve. They could walk away and say, Hey, I did something quite useful in that one session. So for example, it might be placing an order. Just the placement of the order itself is a use case. I don’t have to actually get the product because when I finish placing the order, I can feel quite comfortable and go get a coffee. I’ve done something quite useful. Now updating my profile, that would be a use case as well. Canceling my order. That’s another use case. 

Murray: And how do you represent this in UML?

Howard: In UML you put a little oval for it. If it was, let’s say place an order, we would label that oval Place an order, and that’s the name of the use case.

We would attach a little stick figure that represents the actor, the primary actor that’s the user who is gonna be using that use case is gonna be using that feature. And we put an arrow between them to show the connection between them. That’s the graphical component. And then we start to write up text for that use case. Jacobson has a use case 2.0 that I would really ask your listeners to check up on. It’s a really great update to the whole use case approach for Agile. The minimum that I ask people to write when I’m coaching them is brief description of what it’s about. Preconditions, that’s anything that’s should be true before the user task begins. Post conditions, which is anything that will be true when the task is over. And then the main scenarios. Just a brief description of the main scenarios that would be covered just in a few words. Beyond that a basic flow is written. That’s a series of steps. Typically, it’s up to about nine steps. That says the user does this, the system will do this in response, the user will do this, the system does that. And that’s basically the simplest, cleanest way that a user could get through that task. Assuming that they didn’t make any errors. 

And so in an agile context, that’s about as far as we might go initially. And then we might use that initial set of steps and just walk our stakeholders through it and say, are there any exceptional cases at this step or anything might go wrong at this step or any extra option that you’d like to include and focus on the things that really wanna be included in the very, very first release? Not even necessarily a market release, but the very first release, even to a testing group like our minimum viable product version of this feature.

Murray: Yep. 

Howard: as they start to give us these exceptional cases, there’s, sections in that use case documentation called alternate flows where they describe, what happens in those circumstances. And they don’t have to do it in, a great amounts of text, a simple few words or just a little paragraph or a couple of sentences to explain it is enough. But they can do it step by step as well.

Murray: And how do you turn use cases into user stories? 

Howard: So it’s not as though you’re writing everything up, this whole specification that I described and then splitting it up because that would not be very agile. Instead we focus on the minimum, basic flow, the minimum that would be required for this task to be useful.

And we’d write some of these alternate flows. And then every one of those flows becomes a user story. For example, the basic flow becomes a user story. We might assume that the normal payment would be by Visa, but an alternate flow might be pay against my account. Another alternate flow might be, use my points to make a payment. Another alternate flow might be I want rapid delivery. So there’s an extra charge for that.

I want packaging, I want Signon at the door. And so every one of those becomes a user story. Now, just the one thing I would say is that it doesn’t have to be all the steps that are a user story if we’re not even sure that customers will be wanting to use this feature at all.

For example, when I worked with a telecom company one of the things they wanted to do was to allow people to customize their own plans. Interesting idea, but they didn’t know if their customers would actually be interested in using it . So you could be spending a lot of money eliciting the requirements and developing a product that no one is ever going to use.

This is the problem that Agile is trying to solve, and that agile analysis is trying to solve as well. So instead you might say, all right, let’s take the slimmest possible version of this feature that I could possibly imagine. That would still give me a bit of a read on whether people are interested in this. 

So if it’s ordering something and you don’t know if they wanna order that kind of product or not perhaps when they place the order they’re given an email form to fill out and they send it that way. You haven’t even computerized it. You may decide that a lot of the error checking that would normally go on, in this slim version, you’re not gonna put that in either. You’ll allow ’em to submit something with errors, and a human being will do that checking and then get back to them. And so even though it’s not the most efficient way to do things, it is the most efficient way in terms of not having to do very much programming and getting a result right away.

So what I mean to say is then that you don’t necessarily do all the steps in each flow. you may decide just to do a minimal number of steps in the flow, but that’s the basic way to split up the use case.

Murray: Yeah, I remember doing those. I learnt those from Alistair Coburn’s back in the nineties and I liked it. But there is another contextual problem, which is how do the use cases fit together above that? Is that where user story mapping comes in? 

Howard: So in the use case approach the answer would’ve been business use cases. So a business use case is an interaction not with a computer system, but with a business as a whole. So basically we would gather up a whole bunch of regular use cases, which I call system use cases and say that all of these participate in the same business process. They’re all little pieces, you place an order and then somebody has to fulfill the order and somebody else has to ship the order. And those three system use cases adds up to the business use case.

Murray: So this is a business process use case, is it? 

Howard: That’s right. Exactly. Now a story map is really a very simplified version of that diagram.

Murray: Yep. 

Howard: It’s like a business process model. It’s like a value stream map in that it has the main activities, one after the other, more or less in the order in which they are done. Except it’s a very rough version in a story map. You don’t have diamonds in there saying, under what conditions, this has done versus that is done. We’re not being, very careful that it has to be exactly the way that we say it. It’s a rough outline of the value stream.

Murray: Yep. 

Howard: And that gives you context. What I like is where everything all fits in a story map. Along the top part of the story map, you have the main user tasks that are being done. That need to get done in that value stream, more or less in the order in which they happen. But each of those tasks would take more than a sprint typically to program. So each one of those tasks, which I would call a use case needs to be split into something smaller. And the things that they’re split into are the user stories. And so the user stories get strung out on the bottom of the story map underneath the user task or the use case they support.

Murray: So it’s like a table with columns, which represent the major use cases and rows, which represent the release one, release two, release three, and you put your user stories. So the release one is super minimal, mainly mostly manual. 

Howard: Yes, lots of workarounds. 

Murray: Yeah. And you put your use cases into row one that you absolutely have to do first pass through. 

Howard: Yes. And these don’t have to be full releases where it could be talking about one week sprints. And not only that, but now, we’re doing continuous delivery. So it’s not even that it’s at the end of the sprint that these things are delivered. They’re being delivered throughout. As the stories are being done, they’re being delivered.

Murray: Now this has a very interesting linkage back into Lean startup, lean uX land. Because it strikes me that the minimal process is nothing is automated at all. It’s just everything manual. People are doing it now. Maybe your first step is you put up a webpage, which sends an email so people think they’re filling out a form, but it’s just sending an email.

Howard: You wanna hear worst case of that, the most extreme case, I can’t remember the company that did it. They wanted to have a newsletter or something like that, and they wanted people to subscribe, but they didn’t know if it’d be worth doing. So they put up a click here to subscribe. When the person clicked, they got an error page not found. Now the company looked at how many of these page not found errors they got, and the more they got the more they said, okay, yes.

Murray: It’s not good customer service, but it’s a very cheap way of finding out if people want it. 

Howard: Very cheap and they did it for a brief period. You could do be a lot nicer today. The way how we would do that today is when they click on it, they get a page that comes up and says, it’s not available yet, but it’s coming soon. Give us your name and we’ll keep you up to date on what’s happening. So that’s a little less ugly and you still get the same information. So yeah, that’s actually an mvp and nothing at all has happened. 

One of the companies I was working was an insurance company with usage based insurance. So your insurance benefits and rates and so on are determined not by those general actuarial tables that they use but it’s based upon your own individual habits.

Murray: This is like how many kilometers do you drive a year type of thing? 

Howard: Yes, but it’s much more. What time of day do you drive because nighttime is more dangerous. What areas of the city do you drive in? How fast do you accelerate? How do you stop? So they were starting to put this in. Of course they didn’t know, are people gonna go for this? You could imagine spending months getting all the requirements for this, spending a fortune developing it and finding out that the whole product just falls flat. 

So the very first version of this they did was they offered this UBI to their customers. They gave them benefits immediately that they said if you signed up for a six month trial, you get these and these benefits, which will not go away. But they didn’t actually build the program yet. 

So the idea was if there weren’t enough people all right, these folks are still gonna get those benefits. But we learned a tremendous amount that it wasn’t worth building this program. We saved a huge amount of money. On the other hand, if it turns out that people will give up their privacy concerns, if the benefits are good then it’s worth going ahead. Yeah, that’s an mvp. And yet very little was actually programmed. But you can see just how useful it is. And this is where I think the whole value is. 

We’re talking about what’s the value of the BA in general? It’s all the things that you mentioned, but particularly in an agile context, what is the value? The value is to make sure that the team at all times is working on work items of maximum value. Are they working on the things that are going to bring the most value to the customer base? That is really what their main value is today in an agile environment.

Murray: But isn’t that the role of a product owner in Scrum? So what’s the relationship between the BA and the product owner? 

Howard: The answer to that is yes, it is. The product owner in Scrum includes what a business analyst does. It’s just turned out that in practice, that’s just too much to put onto one person. When the product owner came out a, as a role in Scrum they really wanted to call it a product manager. That’s in fact who they were thinking of. But because product managers were so associated with the Waterfall approach, they had to come up with another name.

Trouble is though, when you get a product manager who’s doesn’t understand Scrum, doesn’t understand business analysis, doesn’t understand the structuring of requirement, all this stuff they don’t do a great job of it. And so the person who is really good at market and analysis and really understands the customer is not the same person necessarily who can work really well with the team.

If they are, that’s fantastic, but often we’re finding that’s not the case. We’re also finding, we just don’t have enough of those product manager types to go around, and just have them working every day with the team when they’ve got a day job to do. And so we found that we need somebody else.

So whether you call that person a proxy product owner, or whether you call the outward looking person, a product manager and the inward looking person, a product owner. Or you have a product owner who is shared amongst a number of teams which is what we often find, but doesn’t do the daily work with the team, and then either a proxy PO or a ba does that kind of daily work with the team. We’re finding that basically what Scrum envisaged as a PO does need to be split generally cuz it’s just too much to put onto one person.

Murray: Yeah, I found that too. 

Howard: And they’ve acknowledged this in the Scrum guide because they’ve now saying that the product owner can delegate all of these responsibilities.

Murray: Yeah. 

Howard: There’s one product owner, but the product owner delegates.

Murray: Yeah. Some teams I was working with recently on a machine learning product had one product owner for a team of 10 people. But they were not able to define the requirements well enough for this very technical team because they didn’t have enough time, they didn’t have any training in any of this stuff. And so I ended up recommending that teams experiment with dedicating engineers to requirements. Basically, we just called it requirements engineer to make everybody happy, but pick some engineers who were good at talking to people, understood what developers need, and were able to do this sort of stuff. And it did help quite a lot.

Howard: Yeah. Absolutely. Absolutely. Generally, when you don’t have people like this on board? What teams have been telling me is that, a number of symptoms. As you mentioned, many of the big jobs don’t get done because the team is focused on little itsy bitsy jobs that have to get done here and there. but a really big job, let’s say we have to change the, whole look and feel, the user interface across the product, these kind of jobs they just never get done. There’s never enough coordination to make that all happen. 

You get delays happening because if somebody has not analyzed the stories in advance of sprint planning, then when you do the sprint plan and people estimate how long it’s gonna take to do the development, they’re making that estimate based on a flawed understanding of what the stories actually are, cuz they haven’t been prepared properly.

Murray: they’re trying to do the business analysis right then and there in 15 minutes in the estimation. 

Howard: You want the sprint planning to go quickly and then if they do an estimation quickly, it often is a flawed estimation because it’s based on the flawed understanding. So they get delays for that reason. They get delays also because there’s, misunderstanding about the requirements. Or you’ve got two teams that are doing things that are connected, but they don’t have the same understanding of the rules, so that, ends up with rework. You get inability to split features into smaller stories that, deliver value. That’s a very difficult thing to do. And if they don’t do it well, you end up with all the stories are very large and they all end up finishing right near the end of the sprint. 

Murray: Or they take multiple sprints? 

Howard: Yeah. That’s of course even worse. But even if they just make it at the end of the sprint, , when you put them all together, if there’s an integration problem you find out so late that you have to delay delivery.

Murray: I find if it’s not done, that there’s a lot of confusion in the team about what they’re supposed to be doing. 

Howard: Yeah 

Murray: And, yeah, it leads to a lot of rework, a lot of spinning wheels. When you come to testing, everybody’s very confused about what you’re supposed to be testing for.

Howard: I’m advocating a lot with teams that they follow some version of the A T D D practice, acceptance driven development, so that before they start working on the feature or even on the story, they understand what the acceptance criteria are

Murray: Is this a definition of done Howard? I think you can say a definition of done includes testable requirements. So we’re gonna write acceptance criteria into our user stories, so flesh em out a bit so that the requirement and the acceptance test criteria are basically the same thing. And then when we are doing the development, we are just gonna automate all those. So there’s no test phase, there’s just we develop automated test cases while we’re building the code. 

Howard: You’re right. I’d actually make it both. You could make this a definition of ready. So a definition of ready would say that before people start working to consider this, to be ready for development, to begin, we want the acceptance criteria defined. And if we’re using the b d d approach, we would, start writing them up in feature files and then to be done, we wanna know that, the automated tests that need to exist do exist, and they’ve been run successfully.

Murray: Yeah. We are big fans of A T D D, continuous delivery and XP. 

Howard: Oh Yeah. Absolutely. The other thing too is that the team is working on the most valuable, work. A lot of that also happens through this continuous negotiation that’s going on. It’s referred to as the triad meetings or I think there was used to be called a Three Amigos.

But it’s basically that you’re continually meeting these three different parties. Somebody representing the customer, like the product owner or somebody who understands basically what’s needed. Somebody who represents the developers, and so they understand the cost of what you’re asking for. Somebody represents testing, who understands testing, so they can look for edge cases. And so that you can continually negotiate how can we squeeze the most value, for the least amount of work. And that negotiation that’s where I find particularly at BA, is very key in an Agile team.

Murray: Or BA’s skills we should say.

Howard: Yes, I’m with you. it’s the competency 

Shane: business analysis is a set of skills. It’s not a role.

Murray: Yeah, it could be done by the product owner or by somebody in the team. If the product owner can’t do it. 

Howard: Yeah. It’s about the competency and I don’t really care that much about what you call that person.

Murray: The other thing I was gonna say about what happens if you don’t do this, Howard, apart from the team getting very confused about what they’re supposed to be doing, is that the architecture gets very confused as well. People get confused about what the tables in the database should be and what the relationships are. They think it’s one to one when it’s one to many, and that sort of change is a big change in architecture. 

Howard: Anyone who’s done development knows that making a cardinality change is a big deal. So yeah. It’s the kind of thing you really don’t want to get wrong. Absolutely. And that’s why I do feel that you need people with those kind of skills to be asking those questions at the right time. I know as a developer, there are oftentimes when I made assumptions. If it wasn’t written down, eh, it’s probably this, and, that’s where you get stuck.

Murray: How do you scale this up across multiple teams in a bigger program. Let’s say you’ve got a hundred people just gotta work on some big thing together and you’ve got 10 teams. how do you scale up this business analysis work?

Howard: Yeah. You’re gonna probably be doing something along the lines of safe. 

Shane: no. Hopefully you’re not right. Hopefully you’re gonna scale. You’re not gonna ruin it.

Murray: let’s, scale without ruining it with SAFE. 

Howard: All right. I think there are some good ideas, and I think the problem is this, when you make everything a rule that you have to do, you run into trouble. Do you need to have an ip innovation and planning iteration every four or five iterations? No, you don’t need to do that. But they say you do have to do it. 

But anyway, let’s say you’ve got a feature coming up that’s gonna be complex that’s going to involve maybe different user groups. Let’s say somebody’s placing an order and to place that order. It involves different types of users and maybe different teams are working with those different users. So as that feature is coming up in the backlog, and if we’re using CanBan, then we would just be looking feature by feature as they’re coming up. If we’re not doing can bend and we’re doing some sort of release planning or quarterly planning, then sometime around about halfway into the previous quarter, we start, doing a little peak. And the idea is to have a somebody like a business analyst at each level of the organization.

So the reason I mentioned the ugly word safe is that although we would have a team level, but we would also have a team of teams that is involved either in a semi-permanent basis as they are in safe, or it could be on an ad hoc basis just to work on this new feature, let’s say. So as you are starting to prepare this feature, maybe about halfway into the previous release, this higher level analyst who’s doing this at the team of teams level. You’re identifying which are the teams that are gonna be involved. You’re getting team commitment from them, and you’re starting to write up acceptance criteria at the feature level, before it breaks down into stories. So this all happens at that higher level. Once you start to break this feature down into individual stories, which can be handled by individual teams. Then it’s the team ba, who’s working with them on that. Although it’s often true too that you don’t have a BA for every team. Instead you have a shared BA as part of an extended team. and in which case that BA is also able to do, that higher level work in between the teams because they’re actually being shared between a group of, let’s say four teams, for example.

Murray: Yeah. So first of all, the ideas in safe come from everywhere else, but they’re not patterns that you can choose between. They’re a rule book that you have to follow. So I’ve seen business analysts write, 10 page epics. Four months ahead of when the team was supposed to do it. Cause you gotta have these things prepared for your PI so that people can plan them. And they do them in a siloed team and everything. Safe is very accommodating of waterfall ways of working. And so people tend to do it that way.

Howard: Yeah. Yeah. And if you talk to the people who develop safe, they’d probably tell you they’re doing it all wrong. The problem doesn’t begin with safe. The problem really begins with Scrum if you wanna get down to it. SAFE is built on Scrum, whether they, say so or not. It’s really Scrum with a extra layer added on top. Scrum itself is extremely inflexible. If you are a scrum master, you have to be doing Scrum exactly as advertised. I just read recently that, if you’re a scrub master, you’re not allowed to teach any competing form of agile.

Murray: Yeah. I’ve seen the scrum Alliance contracts that say that. They say that if you want to be at a scrum Alliance, certified Scrum trainer. You can’t be a scrum trainer for a competitor. And their competitors are defined as scrum.org, scrum at scale and safe, but not IC agile. They seem ok with that.

Howard: I see. And what about if you want teach xp

Murray: They only care about people who are selling scrum master certifications or other things that use their particular terminology. They don’t care about x P certifications because people aren’t selling them so it’s no competition.

Howard: Agile has to be Agile. My approach has always been in my coaching and in my books, . Here’s a toolkit. These are some really useful techniques. Here is where you’re gonna find them useful. Here is where they’re less useful. Encourage you to experiment and, be agile about agile and see what works for you and what doesn’t work for you. And that’s what you go by. That’s more important than anything else. 

Murray: That’s absolutely the key. Be agile about Agile, use agile to implement agile 

Howard: Exactly. A 15 minute standup meeting might not work for you, alright. Why do you have to have that imposed on you if it’s not working and you find another way? Works much better.

Murray: Yeah I agree. There are problems with Scrum. The problems are overcome by it being very short. But when you scale up to three month sprints, then they become difficult. 

Shane: So I find that people that come from a business analyst role, make the most awesome Scrum coaches. Is that your experience and why do you think that is? 

Howard: I don’t know if I could make that general rule, but I would not be surprised because there’s a lot of overlap between what, a scrum coach or a scrum master does, and what a BA does. For example, just communicating the process and making sure that people are following it properly is something that bas are actually really good at and have been doing for a while. I dunno if you have any of you seen the latest IBA nimble report, but they found that when bas are in a leading role, adherence to the agile framework itself is quite high. And when you don’t have a BA in a leading role, it’s actually quite low. They’ve also found that 73% of the most nimble companies have bas in a leading role. And conversely, 69.6% of the least nimble companies do not have a BA in the leading role. And by BA it means somebody’s practicing business analysis. There’s an interesting correlation there for sure. BAS tend to have very good people skills, and they also really understand process. They’re analytical. and that’s the combination that you need as a scrum master. 

Murray: And as a product owner too, I would say. 

Howard: Yeah. Yeah.

Murray: You weren’t ever a ba were you? Shane

Shane: So I came out of pre-sales, which had the same set of T skills as a business analyst. If I mapped my skills in that role with a BA role they were the same skills. We just used it for evil. We didn’t really care about what the requirements were. We just mapped the solution to some requirements you might have had. 

Murray: It’s amazing how we always match 80% of the customer’s requirements, isn’t it?

Shane: Yeah. It’s amazing how 80% of the things they never want do is the things we convince them they need to do. You want one person to be able to join multiple unions. Oh, that’s just a stupid business process. Nobody does that. No customer. We’ve had done that.

Murray: otherwise it’s, that’s just a line of code. We’ll put that. in for you. 

Howard: Oh yeah. Because the person who promises that is not the person who’s gonna have to write that code. I can’t tell you how many times of being on the developer side, having the presales people promise all sorts of things, never having checked with us beforehand 

Shane: Never confuse selling with implementing. 

Howard: This is what ba, should be doing. And this is, by the way, the whole thing really about why agile is better in many ways than the waterfall approach. With the waterfall approach, you had the illusion that because you’re writing up all these detailed requirements and you’re getting signature that you are now secure. But it’s really just an illusion, as you’ve been saying. In Agile, you replace that illusion with actual control because we are continuously delivering working software and we’re getting your response. And if we are way off, you’re gonna know about it pretty soon. There is that immediate course correction.

Murray: All right, Shane, let’s go to summaries. What have you got? 

Shane: Okay, so we started out with answering the first question really, which is, in the world of Agile, as the business analyst disappeared, the BA skills and competencies are still valuable even if the role doesn’t exist in any formal org chart. 

We then talked about subject matter experts and the idea that can a subject matter expert provide those BA skills and I may be able to tie my own neck tie, but I can’t teach you how to do it. So that elicitation that explanation, that ability to distill complexity down into simplicity that somebody else can understand, that’s the core of the skills that a ba typically has. I’m glad you said that moscow as a way of prioritization sucks and you should never do it. But what we really care about is what do we wanna do first? What do we wanna do second, what do we wanna do third? I’ve just written up the chapter of prioritization in my book, and that’s what it’s all about. There’s a window of time. Tell me what’s first, second, and third. Once I get to third and I’m done, tell me what’s first, second, and third. I don’t care how much of it’s a must. Cause if you give me, 80% of them are must we know that by the end of it, you’re not getting 80% of them done. Yeah. We’ll shortcut it. 

Howard: And it’s the value, but also divided by the effort. Everybody wants great things, but it’s also how much does it cost. 

Shane: Yeah. And then I love the idea that’s the business analyst skills provide a shared language. Often the shared language is back to the stakeholder to get confirmation. That’s a skill that we need. I like the idea that it’s the least amount of documentation without doing harm and also that we hold the work until the last responsible moment.

And then the last one for me was use case is a fancy term for usage. Customer places order, customer pays for order, store ships, order customer returns, product. Their use cases. their usage. It was a good conversation for me around, the core of business analysis hasn’t changed. Skills, not roles. Murray, what do you got?

Murray: Yeah I was a business analyst for many years and I think it’s very valuable when it’s done well. I see a lot of teams not having a BA role or somebody who’s doing business analysis and they get very confused about what they’re doing and how to know whether it’s done and what the architecture should be. So what ends up happening is that somebody else steps in and tries to do it. So the product owner might try and do it, or the software architect or the team lead or UX designers will often start doing it because it needs to be done regardless of whether you have somebody called a business analyst or not. Somebody in that team needs to be able to flesh out the business process that we are automating with software? 

What are the use cases within that business process, which is things like, create a user or add a insurance case or update an insurance claim. And then what are the user stories, which are the small parts of the use case that we can slice off and give to a team to build within a couple of weeks.

It absolutely has to be done. Somebody has to do it at some point. It’s part of good product development, good system development practice. If you don’t do it, you get yourself into a terrible mess. But it does not have to be done, with a big requirements document three months up front. That in fact leads to quite bad outcomes and frequently people don’t read them. It gives you the illusion of fixing the requirements so that you can contract people to deliver them and sue them if they don’t. But it never works that way because there is always a lot of changes, because it’s not possible to know all of the requirements a hundred percent accurately upfront. It’s simply impossible. Product development and software development is a process of learning what’s needed as you go. 

Howard: yeah. I was working with a large financial company and you would think that this was one where you would really would know what the requirements are. It was a compliance project. They had to put in some reporting features and various tracking features so that they would comply with government regulations in order to take on consultancy work from the government. So you’d think that this is pretty, pretty straightforward, right? it turned out there was also a lot of gold plating on that. Once they started to, put the requirements together any manager who would seen any kind of a product which had lovely features, they just added it into the requirements even though it wasn’t really needed for compliance with the government. And so, this idea from agile of really focusing on the minimum marketable product, the minimum marketable features turned out to be very helpful for them.

Murray: Yeah, I think so too. And also gold plating the requirements means that you’re going gold plate the architecture and the design and everything is gonna be 10 times bigger than it needs to be because some manager saw it in some product somewhere and said it was a must have.

Howard: Yeah, a lot of those little extras out to be the most expensive thing in the entire system. And they’re not even needed.

Murray: Yeah, so we know from research by the Standish Chaos Group, and also more recently by Pendo that 70 to 80% of the product features we build are rarely or never used.

Howard: Yeah. I’ll give you one quick example. A company that was working for one of the provincial governments here, was it basically an incident management system that they were putting in. And the most expensive part of it was for very serious incidents that happened where they had to connect to external systems , to contact the police, other levels of government, and so on. It turned out that incidents of that type were so rare and they really did require human intervention , that there was really no need to put them in the system and put them in the product, and yet they were the most expensive aspects of the product. 

Murray: Yeah. Mind you, if you’re Accenture though that’s great. They’re paying 10 times more than they would’ve. So I think that there is a lot of uncertainty in all software projects. Even ones which are replatforming. It was on sun, build it again on Oracle. There’s still considerable uncertainty because people are always changing what they understand what it did before. People have forgotten. I would say an agile approach is always better. The other thing is, as you said, It’s a really great way to focus on what’s really important. You do your high level user story map. You identify your use cases and what are your minimal stories. You work on those first, maybe you mock them up as UX prototypes and test them.

Howard: Yeah. 

Murray: You get that feedback and that learning straight away, and you use that to refine what you’re doing. And then you can really focus on what delivers the most value for money. And that is really important. Because projects or products or initiatives always have a limited amount of time and money and there’s always more scope than you can possibly do. So it’s very important that you do this constant prioritization and that you allow space and time to learn as you go.

Howard: That’s right. So you should never fix that plan. You’re learning as you go means that you’re giving yourself that room to respond to what you learn and make changes to the plan as you go. It might be a small thing like changing the acceptance criteria on a feature and making it a little bit more minimal. It might be dropping feature altogether, and it could be, even much more than that. It might be a total pivot on the product itself.

Murray: Yeah. I think Agile is actually very good at delivering to a goal within a fixed time and budget because you can keep the scope variable. You’ve got a team of 10 people for six months and we wanna achieve this goal and it has these measurable outcomes. There’s so many ways of doing it that if we just focus on the most important things, we can always be sure to get there.

Howard: Yeah. we focus on the outcome. But as far as the actual features, they may change over time. 

Murray: Yeah. Yeah. So for example, if somebody says, I want search in my product. Search, depending on how you define it as a requirement, could be free. Cause it’s outta the box. What could be 10 billion dollars cause it’s Google. 

Howard: Yes, exactly. Yeah.

Murray: how much money have you got? 

Howard: Exactly.

Murray: Yeah, so this has been good. I think it’s such a shame that business analysis is missing from a lot of teams and needs to come back. It’s a very important skill. There is good training. Now, for instance, you offer training, don’t you, Howard? 

Howard: Yeah. So actually we’re doing a workshop with, IT Works out of Belgium. If people just follow me on LinkedIn they’ll find out about it. I’ve got my own book the Agile guide to Business Analysis and Planning which walks you through the initial idea for a product all the way down to the detailed stories as you start to develop it. Just basically what kind of techniques you would use at every step along the way of developing that product. 

You follow a case study along the way as well with that book, so you can actually just work hands on with it if you want as well, if you wanna get that deep. So yeah, I did that really to try to help people in this position. I looked at techniques across all of these methodologies that you spoke about at the beginning of our talk, lean Startup, mvp, CanBan and of course Scrum and so on. And trying to put all those together into a coherent picture for people and give them the choices of what kind of techniques to use when.

Murray: That’s great. And your website, Howard.

Howard: So the website is www dot noble, inc. n o l e i n c ca,

Murray: Okay. And people can find you on LinkedIn as well, Howard podeswa 

Howard: Yeah, yeah.

Murray: All right. That’s great. Thanks for coming on, Howard.

Howard: It’s been a pleasure.