1
00:00:00,320 --> 00:00:04,360
The Better Business Analysis 
Institute presence, The Better 

2
00:00:04,360 --> 00:00:07,680
Business Analysis Podcast with 
Benjamin Walsh. 

3
00:00:12,520 --> 00:00:15,320
Hi everybody and welcome back to
the Better Business Analysis 

4
00:00:15,320 --> 00:00:19,120
podcast with Benjamin Walsh. 
And this week we continue our BA

5
00:00:19,320 --> 00:00:22,560
Bytes series and we're going to 
be talking about what the hell 

6
00:00:22,560 --> 00:00:25,960
is a feature. 
This is a topic that is been 

7
00:00:25,960 --> 00:00:30,040
playing on my mind for a while, 
and I kind of think I haven't 

8
00:00:30,040 --> 00:00:34,200
met anyone who's confident 
enough to stand up on a pedestal

9
00:00:34,200 --> 00:00:38,120
and actually explain to me what 
a feature is when applied to all

10
00:00:38,120 --> 00:00:40,160
situations. 
They might be comfortable in 

11
00:00:40,160 --> 00:00:43,400
their dev environment talking 
about it, but actually I think 

12
00:00:43,480 --> 00:00:48,040
that the definition of feature 
has changed over time and I'm 

13
00:00:48,040 --> 00:00:52,760
going to suggest a change that 
might help you with the way you 

14
00:00:52,760 --> 00:00:56,680
manage requirements if you've 
been following development 

15
00:00:56,800 --> 00:01:01,680
driven methodology to date. 
Let's get into what the hell is 

16
00:01:01,680 --> 00:01:07,600
a feature Before we, I guess, 
jump into the way in which we 

17
00:01:07,600 --> 00:01:11,840
use features, I think it's 
important for us to talk about 

18
00:01:11,840 --> 00:01:16,960
the original definition. 
So originally, features were 

19
00:01:16,960 --> 00:01:22,160
defined as a distinct attribute 
or capability of a product that 

20
00:01:22,160 --> 00:01:24,720
set itself apart from 
competitors. 

21
00:01:25,680 --> 00:01:28,840
And this was often highlighted 
to showcase what the product 

22
00:01:28,840 --> 00:01:33,000
could do and how it could do it 
to solve a specific problem. 

23
00:01:33,400 --> 00:01:36,200
And we still use that word. 
We still talk about product 

24
00:01:36,200 --> 00:01:38,440
features. 
When we go to a website and 

25
00:01:38,440 --> 00:01:41,400
we're looking up a new tool, 
it'll list all the features it 

26
00:01:41,400 --> 00:01:44,600
has. 
OK, that's actually a term that 

27
00:01:44,640 --> 00:01:49,520
is used in the market. 
But today, the concept of 

28
00:01:49,520 --> 00:01:53,640
features has evolved quite far 
away from that when it comes to 

29
00:01:53,640 --> 00:01:55,320
software development and the 
world of BA. 

30
00:01:56,280 --> 00:02:01,480
Features are now seen as first 
class entities used throughout 

31
00:02:01,480 --> 00:02:05,200
the software development life 
cycle to analyze, design, 

32
00:02:05,200 --> 00:02:08,039
implement, customize, debug and 
evolve a system. 

33
00:02:08,880 --> 00:02:12,480
That integral in the 
methodologies like Feature 

34
00:02:12,480 --> 00:02:16,840
driven development, Agile, 
focusing on continuous 

35
00:02:16,840 --> 00:02:19,960
improvement, incremental 
delivery of software by breaking

36
00:02:19,960 --> 00:02:23,720
it down from I guess the 
software development process 

37
00:02:23,960 --> 00:02:28,200
into manageable feature sets. 
And in modern software 

38
00:02:28,200 --> 00:02:33,240
development, features are often 
driven by user needs and 

39
00:02:34,080 --> 00:02:38,400
objectives, right? 
But and the user centric. 

40
00:02:38,400 --> 00:02:43,640
So I have to say that, but 
ultimately they're defining 

41
00:02:45,320 --> 00:02:49,400
overall needs in a solution way,
in a solution way. 

42
00:02:50,280 --> 00:02:55,400
And that for me is a problem. 
So let's give you an example of 

43
00:02:55,400 --> 00:02:58,800
how it's used today. 
OK, This is the way in which 

44
00:02:59,400 --> 00:03:01,680
most development teams are 
working. 

45
00:03:03,040 --> 00:03:07,200
And some of our systems like 
Azure DevOps is set up as well 

46
00:03:07,200 --> 00:03:10,920
as a JIRA in some cases is even 
set up to reinforce this. 

47
00:03:10,920 --> 00:03:12,320
OK, so I'm going to explain 
this. 

48
00:03:12,320 --> 00:03:16,480
This is typical agile. 
There's, there are themes, 

49
00:03:16,480 --> 00:03:17,760
objectives. 
We're going to figure out about 

50
00:03:17,760 --> 00:03:20,240
those for a second. 
And let's say we have an epic 

51
00:03:20,280 --> 00:03:24,320
that's around improving user 
authentication. 

52
00:03:24,320 --> 00:03:27,200
Obviously that's not how you 
write epics, but I'm just 

53
00:03:27,200 --> 00:03:30,320
paraphrasing here. 
And then under the epoch you'll 

54
00:03:30,320 --> 00:03:35,040
have a feature like implement 
multi factor authentication and 

55
00:03:35,040 --> 00:03:37,200
then under that you'll have user
stories. 

56
00:03:37,200 --> 00:03:42,120
As a user I want to receive a 
notifica notification code on my

57
00:03:42,120 --> 00:03:45,200
phone when I enter my password 
so I can log in securely. 

58
00:03:45,200 --> 00:03:50,760
Or as an admin I want to 
configure MFA settings for 

59
00:03:50,760 --> 00:03:53,600
different user roles so I can 
enhance security based on user 

60
00:03:53,600 --> 00:03:55,160
needs. 
Logical. 

61
00:03:55,160 --> 00:04:00,480
Does that sound familiar to you?
This is how many product teams 

62
00:04:00,480 --> 00:04:03,000
are using epochs, features and 
user stories. 

63
00:04:05,080 --> 00:04:09,760
They're mapping down to the 
components and then they've got 

64
00:04:09,760 --> 00:04:14,280
the user stories which are the 
features or sub features though 

65
00:04:14,800 --> 00:04:18,839
functionals and non functional 
considerations underneath that. 

66
00:04:19,320 --> 00:04:25,240
It seems elegant and it seems 
right now why am I challenging 

67
00:04:25,240 --> 00:04:27,280
that? 
Why do I think that is a really 

68
00:04:27,760 --> 00:04:33,600
not a very good way of using the
concept of a feature? 

69
00:04:34,560 --> 00:04:37,800
So it's a hierarchical for one. 
So it's structured epic to 

70
00:04:37,800 --> 00:04:41,440
feature to user story and a lot 
of these tools bake in that. 

71
00:04:41,440 --> 00:04:45,160
So you're literally epic feature
user story. 

72
00:04:45,480 --> 00:04:51,160
But the reason I have a problem 
with this approach is that at 

73
00:04:51,160 --> 00:04:56,760
your epic level and let's say it
was improving security, 

74
00:04:56,760 --> 00:05:00,600
improving authentication or 
providing a secure way in which 

75
00:05:00,600 --> 00:05:04,680
our users can access our product
or our website. 

76
00:05:05,040 --> 00:05:08,560
How do you know at that stage 
when you're you've not got any 

77
00:05:08,560 --> 00:05:12,920
development team, how do you 
know what features you need to 

78
00:05:12,920 --> 00:05:14,120
do that? 
Let's say it was something 

79
00:05:14,120 --> 00:05:16,960
completely new, not a product 
that you've been working on. 

80
00:05:17,200 --> 00:05:20,000
So it's not like adding features
to an existing product, which is

81
00:05:20,000 --> 00:05:23,840
where the current way we use it 
for and that's why it works and 

82
00:05:23,840 --> 00:05:26,320
product teams well. 
But let's say it's something 

83
00:05:26,320 --> 00:05:28,800
you, you literally have never 
built before. 

84
00:05:29,640 --> 00:05:34,000
You have no idea what the 
technical components or the comp

85
00:05:35,600 --> 00:05:39,000
features are. 
Literally they're features you 

86
00:05:39,000 --> 00:05:42,800
want to build. 
OK, you've never done this 

87
00:05:42,800 --> 00:05:47,000
before, so I would say that your
epic actually should join down 

88
00:05:47,000 --> 00:05:50,600
to a high level user story 1st 
and I'm going to come back with 

89
00:05:50,600 --> 00:05:57,200
an example and explain why in a 
process driven environment, not 

90
00:05:57,200 --> 00:06:01,560
a product of an environment, 
there is no feature per SE. 

91
00:06:01,960 --> 00:06:07,120
OK. 
The feature could be 

92
00:06:07,480 --> 00:06:11,320
improvement, they could be 
improvement to process steps. 

93
00:06:11,440 --> 00:06:14,000
So you could say we've done 
current. 

94
00:06:14,240 --> 00:06:17,480
State Analysis. 
We've defined some goals and 

95
00:06:17,480 --> 00:06:23,400
maybe the feature improvement is
automate data entry or implement

96
00:06:23,400 --> 00:06:26,920
quality checks and then the 
requirement could come off that.

97
00:06:28,560 --> 00:06:33,920
But again, automating data 
entry, which could result in a 

98
00:06:33,920 --> 00:06:38,600
technical change is the feature 
has lost all meaning. 

99
00:06:38,800 --> 00:06:42,240
Now the feature just becomes a 
high level requirement. 

100
00:06:43,440 --> 00:06:46,000
So it's inconsistent from the 
product world because in this 

101
00:06:46,000 --> 00:06:50,120
case in the process world, we 
are literally defining a 

102
00:06:50,120 --> 00:06:53,240
requirement, automate data 
entry, which is just a high 

103
00:06:53,240 --> 00:06:56,120
level requirement in the back in
the day, a business requirement.

104
00:06:56,600 --> 00:07:00,200
But then over in the other world
and product, we've literally 

105
00:07:00,200 --> 00:07:06,440
talked about implementing Mon 
Monty, sorry, multi factor 

106
00:07:06,440 --> 00:07:10,880
authentication MFA, which is 
actually a technical solution, 

107
00:07:10,880 --> 00:07:15,240
which is actually a reply to a 
process problem. 

108
00:07:16,240 --> 00:07:18,600
So what I'm saying is it's 
completely inconsistent about. 

109
00:07:18,600 --> 00:07:20,200
What the definition of a feature
is. 

110
00:07:21,200 --> 00:07:25,040
So coming back to what I 
suggested before, the best 

111
00:07:25,040 --> 00:07:28,640
approach for dealing with 
features is to define your user 

112
00:07:28,640 --> 00:07:32,360
stories first. 
The high level user stories, 

113
00:07:32,360 --> 00:07:34,800
you're using user stories to 
define your first kit. 

114
00:07:35,080 --> 00:07:36,600
They are not static user 
stories. 

115
00:07:36,600 --> 00:07:39,280
OK, so your first kind of high 
level requirements are user 

116
00:07:39,280 --> 00:07:44,280
stories. 
Then work with your architect to

117
00:07:44,920 --> 00:07:49,080
identify features based on those
user stories. 

118
00:07:49,240 --> 00:07:53,480
They should all, they should 
probably be high level technical

119
00:07:53,480 --> 00:08:01,240
components like implement an 
ordering tracking system or what

120
00:08:01,240 --> 00:08:03,880
are ingestion and processing of 
data. 

121
00:08:04,080 --> 00:08:06,320
OK, high level things that you 
can talk about with an 

122
00:08:06,320 --> 00:08:08,560
architect. 
You haven't even bothered with 

123
00:08:08,560 --> 00:08:11,600
the development team yet, which 
is great because you've saved 

124
00:08:11,600 --> 00:08:15,240
time and cost of money. 
Then once you've agreed that 

125
00:08:15,240 --> 00:08:19,080
these features, these are 
probably the features that need 

126
00:08:19,080 --> 00:08:21,120
to be done conceptually at a 
high level. 

127
00:08:21,120 --> 00:08:24,080
So you're not using this and the
feature level of feature of a 

128
00:08:24,080 --> 00:08:26,120
product. 
You're literally defining these 

129
00:08:26,120 --> 00:08:30,920
high level groupings. 
You can even write your story as

130
00:08:30,920 --> 00:08:33,400
a user story. 
I want to perform action which 

131
00:08:33,400 --> 00:08:36,440
is different to use feature. 
Form action is different to use 

132
00:08:36,440 --> 00:08:38,919
feature. 
Use feature is the response 

133
00:08:39,640 --> 00:08:43,880
perform action with technical 
component X or with feature. 

134
00:08:43,880 --> 00:08:46,280
If you're using feature this 
definition that I'm suggesting 

135
00:08:46,280 --> 00:08:52,080
you should, then you can then 
break down your detail 

136
00:08:52,080 --> 00:08:54,920
requirements off the feature and
the user story. 

137
00:08:55,200 --> 00:08:58,800
So it's really a side join to 
the feature, which is useful 

138
00:08:58,800 --> 00:09:03,200
because it's a good way of the 
technical team going. 

139
00:09:03,960 --> 00:09:07,080
Some of these detail 
requirements don't match, so 

140
00:09:07,080 --> 00:09:10,680
maybe we didn't identify all the
features and it's not their job 

141
00:09:10,680 --> 00:09:13,120
to do so that you know, this 
project might evolve. 

142
00:09:14,040 --> 00:09:16,520
It's also a good way of just 
looking at the user story down 

143
00:09:16,520 --> 00:09:19,680
to the requirement level. 
So sorry, and I will confirm 

144
00:09:19,680 --> 00:09:21,960
what I mean by that. 
User stories can have child user

145
00:09:21,960 --> 00:09:23,320
stories. 
So that's just a way of doing 

146
00:09:23,320 --> 00:09:24,920
it. 
You just break them down 

147
00:09:24,920 --> 00:09:27,760
further. 
And then you could your user 

148
00:09:27,760 --> 00:09:30,400
story is breaking down to these 
these requirements or child user

149
00:09:30,400 --> 00:09:32,120
stories, which are non 
functional functional 

150
00:09:32,120 --> 00:09:34,280
requirements also join with a 
feature. 

151
00:09:34,880 --> 00:09:38,240
OK, so I'll give you an example.
User story 1 high level 

152
00:09:38,240 --> 00:09:43,560
requirement As a as a customer, 
I want to track my online status

153
00:09:45,400 --> 00:09:49,640
for my order so that I know 
where my package will arrive. 

154
00:09:50,520 --> 00:09:53,800
OK, that's a pretty standard 
user story As a customer, I want

155
00:09:53,800 --> 00:09:57,640
to track my order status online 
so I know where my package 

156
00:09:57,640 --> 00:09:58,240
arrives. 
Right. 

157
00:09:58,240 --> 00:09:59,840
That's pretty standard. 
Perfect. 

158
00:10:00,360 --> 00:10:05,520
It's a a great process driven, 
journey mat driven user story. 

159
00:10:06,800 --> 00:10:11,960
The feature to match to that the
architects could say, instead of

160
00:10:11,960 --> 00:10:16,880
using feature in the definition 
of functions of a system or how 

161
00:10:16,880 --> 00:10:19,840
you do it, have you used 
features to talk about technical

162
00:10:19,840 --> 00:10:23,880
components like I'm suggesting? 
The architect could say, look, I

163
00:10:23,880 --> 00:10:26,000
have no idea what it is, but I 
think you're talking about an 

164
00:10:26,000 --> 00:10:29,400
ordering system, right? 
An order tracking system of some

165
00:10:29,400 --> 00:10:31,600
description. 
Perfect they. 

166
00:10:31,600 --> 00:10:34,120
Haven't even. 
They don't know how that looks. 

167
00:10:34,120 --> 00:10:37,200
They don't know all the. 
Bells and whistles, they don't 

168
00:10:37,200 --> 00:10:39,760
that's it's conceptual, they 
could go out to market to look 

169
00:10:39,760 --> 00:10:45,680
for it, right. 
And then in parallel of breaking

170
00:10:45,680 --> 00:10:48,920
down the user story and looking 
for solutions to the feature, 

171
00:10:49,880 --> 00:10:53,000
you could then breakdown things 
and go, OK, well now we've got, 

172
00:10:53,120 --> 00:10:58,240
we are going to implement a new 
orderings order tracking system.

173
00:10:58,240 --> 00:11:01,240
We've decided to do that. 
We're going to buy one and we 

174
00:11:01,240 --> 00:11:04,480
need, we now have requirements 
for that detailed requirements. 

175
00:11:04,920 --> 00:11:09,600
So it could be allowing users to
enter the order number, display 

176
00:11:09,600 --> 00:11:12,600
current order status. 
You know these are all child 

177
00:11:12,600 --> 00:11:16,000
user stories now, right? 
Which join right up to tracking 

178
00:11:16,000 --> 00:11:21,320
order the user story and blank 
to features or could be bundled 

179
00:11:21,320 --> 00:11:25,800
against features. 
The decoupling allows you also 

180
00:11:25,800 --> 00:11:28,920
because a user story might be 
met by multiple features 

181
00:11:29,200 --> 00:11:37,320
components, OK, or the user 
story might be met by a whole 

182
00:11:37,320 --> 00:11:40,920
lot of different requirements in
which only some are technical 

183
00:11:41,160 --> 00:11:46,680
and some are process based. 
So if you don't have a technical

184
00:11:46,680 --> 00:11:50,000
feature, then you won't have it.
So therefore you could have as a

185
00:11:50,000 --> 00:11:55,720
user, I want to train a 
customer, sorry, as a customer, 

186
00:11:55,720 --> 00:11:59,520
I want to be trained on how to 
look up my order status. 

187
00:11:59,520 --> 00:12:02,800
So I understand the process and 
I understand where to look. 

188
00:12:03,320 --> 00:12:06,720
Now the feature could be, you 
know, a web page which explains 

189
00:12:06,720 --> 00:12:10,440
content, right? 
Or it could be just a process 

190
00:12:10,440 --> 00:12:12,480
step that, you know, if our 
customer was like a 

191
00:12:12,480 --> 00:12:16,600
multinational big business, we 
might, one of our actions might,

192
00:12:17,040 --> 00:12:19,840
our requirements might be doing 
some training with them. 

193
00:12:20,160 --> 00:12:22,640
And yes, you could define that 
as a process feature. 

194
00:12:23,560 --> 00:12:27,600
So I think the point here is 
that features are not a 

195
00:12:27,600 --> 00:12:31,240
constraint above a user story. 
They are responses to your high 

196
00:12:31,240 --> 00:12:34,360
level user stories in which the 
requirements could drop out of 

197
00:12:34,600 --> 00:12:38,160
as which has a join to the 
parent user story. 

198
00:12:38,680 --> 00:12:42,360
OK, so my definition of a 
feature, What the hell is a 

199
00:12:42,360 --> 00:13:17,240
feature? 
So my definition of a feature is

200
00:13:17,240 --> 00:13:20,400
a tangible technical component 
or subcomponent that is needed 

201
00:13:20,400 --> 00:13:23,360
to satisfy the requirements of 
the project. 

202
00:13:23,360 --> 00:13:26,160
I hope you learned something 
today, or at least challenge 

203
00:13:26,160 --> 00:13:29,000
your thinking and I will see you
next week.