The Better Business Analysis Institute presence, The Better Business Analysis Podcast with Benjamin Walsh. Hi everybody and welcome back to the Better Business Analysis podcast with Benjamin Walsh. And this week we continue our BA Bytes series and we're going to be talking about what the hell
is a feature. This is a topic that is been playing on my mind for a while, and I kind of think I haven't met anyone who's confident enough to stand up on a pedestal and actually explain to me what a feature is when applied to all
situations. They might be comfortable in their dev environment talking about it, but actually I think that the definition of feature has changed over time and I'm going to suggest a change that might help you with the way you manage requirements if you've been following development driven methodology to date. Let's get into what the hell is a feature Before we, I guess, jump into the way in which we use features, I think it's important for us to talk about
the original definition. So originally, features were defined as a distinct attribute or capability of a product that set itself apart from competitors. And this was often highlighted to showcase what the product could do and how it could do it to solve a specific problem. And we still use that word. We still talk about product features. When we go to a website and we're looking up a new tool, it'll list all the features it has. OK, that's actually a term that
is used in the market. But today, the concept of features has evolved quite far away from that when it comes to software development and the world of BA. Features are now seen as first class entities used throughout the software development life cycle to analyze, design, implement, customize, debug and evolve a system.
That integral in the methodologies like Feature driven development, Agile, focusing on continuous improvement, incremental delivery of software by breaking it down from I guess the software development process into manageable feature sets. And in modern software development, features are often driven by user needs and objectives, right? But and the user centric. So I have to say that, but ultimately they're defining overall needs in a solution way, in a solution way.
And that for me is a problem. So let's give you an example of how it's used today. OK, This is the way in which most development teams are working. And some of our systems like Azure DevOps is set up as well as a JIRA in some cases is even set up to reinforce this. OK, so I'm going to explain this. This is typical agile. There's, there are themes, objectives. We're going to figure out about those for a second. And let's say we have an epic that's around improving user authentication.
Obviously that's not how you write epics, but I'm just paraphrasing here. And then under the epoch you'll have a feature like implement multi factor authentication and then under that you'll have user stories. As a user I want to receive a notifica notification code on my phone when I enter my password so I can log in securely. Or as an admin I want to configure MFA settings for different user roles so I can enhance security based on user needs. Logical.
Does that sound familiar to you? This is how many product teams are using epochs, features and user stories. They're mapping down to the components and then they've got the user stories which are the features or sub features though functionals and non functional considerations underneath that. It seems elegant and it seems right now why am I challenging that? Why do I think that is a really not a very good way of using the concept of a feature?
So it's a hierarchical for one. So it's structured epic to feature to user story and a lot of these tools bake in that. So you're literally epic feature user story. But the reason I have a problem with this approach is that at your epic level and let's say it was improving security, improving authentication or providing a secure way in which our users can access our product or our website.
How do you know at that stage when you're you've not got any development team, how do you know what features you need to do that? Let's say it was something completely new, not a product that you've been working on. So it's not like adding features to an existing product, which is where the current way we use it for and that's why it works and product teams well. But let's say it's something you, you literally have never built before.
You have no idea what the technical components or the comp features are. Literally they're features you want to build. OK, you've never done this before, so I would say that your epic actually should join down to a high level user story 1st and I'm going to come back with an example and explain why in a process driven environment, not a product of an environment, there is no feature per SE. OK. The feature could be improvement, they could be improvement to process steps.
So you could say we've done current. State Analysis. We've defined some goals and maybe the feature improvement is automate data entry or implement quality checks and then the requirement could come off that. But again, automating data entry, which could result in a technical change is the feature has lost all meaning. Now the feature just becomes a high level requirement.
So it's inconsistent from the product world because in this case in the process world, we are literally defining a requirement, automate data entry, which is just a high level requirement in the back in the day, a business requirement. But then over in the other world and product, we've literally talked about implementing Mon Monty, sorry, multi factor authentication MFA, which is actually a technical solution, which is actually a reply to a process problem.
So what I'm saying is it's completely inconsistent about. What the definition of a feature is. So coming back to what I suggested before, the best approach for dealing with features is to define your user stories first. The high level user stories, you're using user stories to define your first kit. They are not static user stories. OK, so your first kind of high level requirements are user stories. Then work with your architect to identify features based on those user stories.
They should all, they should probably be high level technical components like implement an ordering tracking system or what are ingestion and processing of data. OK, high level things that you can talk about with an architect. You haven't even bothered with the development team yet, which is great because you've saved time and cost of money. Then once you've agreed that these features, these are probably the features that need to be done conceptually at a high level.
So you're not using this and the feature level of feature of a product. You're literally defining these high level groupings. You can even write your story as a user story. I want to perform action which is different to use feature. Form action is different to use feature. Use feature is the response perform action with technical component X or with feature.
If you're using feature this definition that I'm suggesting you should, then you can then break down your detail requirements off the feature and the user story. So it's really a side join to the feature, which is useful because it's a good way of the technical team going. Some of these detail requirements don't match, so maybe we didn't identify all the features and it's not their job to do so that you know, this project might evolve.
It's also a good way of just looking at the user story down to the requirement level. So sorry, and I will confirm what I mean by that. User stories can have child user stories. So that's just a way of doing it. You just break them down further. And then you could your user story is breaking down to these these requirements or child user stories, which are non functional functional requirements also join with a feature.
OK, so I'll give you an example. User story 1 high level requirement As a as a customer, I want to track my online status for my order so that I know where my package will arrive. OK, that's a pretty standard user story As a customer, I want to track my order status online so I know where my package arrives. Right. That's pretty standard. Perfect. It's a a great process driven, journey mat driven user story.
The feature to match to that the architects could say, instead of using feature in the definition of functions of a system or how you do it, have you used features to talk about technical components like I'm suggesting? The architect could say, look, I have no idea what it is, but I think you're talking about an ordering system, right? An order tracking system of some description. Perfect they. Haven't even. They don't know how that looks.
They don't know all the. Bells and whistles, they don't that's it's conceptual, they could go out to market to look for it, right. And then in parallel of breaking down the user story and looking for solutions to the feature, you could then breakdown things and go, OK, well now we've got, we are going to implement a new orderings order tracking system. We've decided to do that. We're going to buy one and we need, we now have requirements for that detailed requirements.
So it could be allowing users to enter the order number, display current order status. You know these are all child user stories now, right? Which join right up to tracking order the user story and blank to features or could be bundled against features. The decoupling allows you also because a user story might be met by multiple features components, OK, or the user story might be met by a whole lot of different requirements in which only some are technical
and some are process based. So if you don't have a technical feature, then you won't have it. So therefore you could have as a user, I want to train a customer, sorry, as a customer, I want to be trained on how to look up my order status. So I understand the process and I understand where to look. Now the feature could be, you know, a web page which explains
content, right? Or it could be just a process step that, you know, if our customer was like a multinational big business, we might, one of our actions might, our requirements might be doing some training with them. And yes, you could define that as a process feature. So I think the point here is that features are not a
constraint above a user story. They are responses to your high level user stories in which the requirements could drop out of as which has a join to the parent user story. OK, so my definition of a feature, What the hell is a feature? So my definition of a feature is a tangible technical component or subcomponent that is needed to satisfy the requirements of the project. I hope you learned something today, or at least challenge your thinking and I will see you next week.