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.