Well, let's get started.

We start off a little bit with you telling me, give me like a two minute overview of
your experience
as a business analyst.
Sure.
So I've been consulting as a VA, and some of the key skills I've been doing is the
first thing I do
whenever I start up a project is make myself familiar with the scope of the
project, understanding the high level requirements.
Also make myself familiar with the business processes, the business jargons.
If there are any existing systems, I'd like to make myself familiar with the
current, with the way
how it currently works, and then start the brainstorming sessions with the
business, helping identify
business rules, functional requirements, UI requirements, and then whatever we
take, whether creating a functional requirements document or use case
approach, or if it's agile writing user stories and support them with UML diagrams
like use case diagrams, activity diagrams, support them with wireframes.
UX specification.
Also, I've been working closely with the QA team if needed to help them write
test cases, conduct
manual testing, conduct bug triages between testers and the developers,
coordinating the user acceptance
testing and also writing release notes.
So that's primarily what I've been doing.
Is this what you were expecting or you wanted me to talk about something
specific?
No, that's great.
That's perfect.
We're just going to probably expand on some more of the things that you
brought up in this in your overview
so we can kind of assess your skills.
But so far, sure, definitely.
Um, the experience we're looking for.
Um, so in.
Let's see.
So you said you mentioned Agile.
Let's touch on that first.
So are you familiar with the Agile methodology?
Yes, I am familiar with Agile and I believe I wouldn't say I'm a Superman or a pro,
but I have a pretty good grasp at it.
Okay.
So you've worked on projects.
Are you currently working on a project?
That's.
That's correct.
Okay.
How long are your typical sprints?
So a sprint in this case is a week sprint.
I also worked prior where there were two week sprint.
So we have a we have a monthly release and there are four sprints in the
release.
Okay.
Now.
I guess with, you know, 1 to 2 week sprints there.
Um, how do you go about documenting your requirements in that short period of
time?
So the way I work is I typically work, uh, probably a release cycle ahead of time.
So it's not that I'll have, uh, the features, I'll end up writing user stories right
before the beginning
of the sprint.
My goal is to have a good list of or a good inventory of ready to code user stories
that the developers can pick up on.
Because many times what happens is when I do a sprint sprint planning meeting
with them, sometimes
I feel a user story which is ready from my end may lack some details at times.
I'm human.
And then.
And then I have to discard that user story because it's not ready to code because
I missed out on certain
details.
So then I always ensure that I have a couple of other user stories or more than
couple for them to pick
up on so that they don't remain idle.
So I always like to work.
Probably a good idea is about 3 to 4 sprints ahead of cycle so that I manage a
good inventory of user
stories.
Okay.
Now have you also functioned as you function as the product owner or is that
correct?
Correct.
As a product owner, I mean, do you think if I can give you more like a two minute
overview of my experience
on Agile will give you a better understanding of my experience?
Okay.
I'm just going to ask some questions.
It's good.
Okay, cool.
We um, function in agile environment, so I was just making sure that you have
experience with that.
It wouldn't be a showstopper if you didn't because, you know, in my opinion,
Agile is, you know,
it's easy to pick up and learn how teams everything functions differently from a
and from a buyer perspective.
I'm in so much in love with Agile because it makes my life it makes my life so
easy when it comes to documentation because I don't have to manage the 200
page requirement document.
I keep a track of what's changing and whatnot.
So right.
So in your, you know, working in Agile, do you guys work with any kind of
requirements tool or simply go ahead?
Nope.
I mean, currently using rally for that.
Initially, it all started with an Excel spreadsheet.
Even the backlog would be in an Excel spreadsheet.
And later we thought we need to have a more civilized approach and hence we
migrated, migrated to rally.
Okay.
I've also.
Oh, go ahead.
No, I just I'm also a little bit familiar with Jira.
I've not used it on any of my projects, but I'm a little bit nerd when it comes to
some new tools,
so I just like a trial version of it and just play play with it.
So I've not used it in a work environment.
Just have an overview of what it is.
Okay.
Yeah.
We're currently in our scrum teams using TFS is what we're utilizing just for, you
know, tracking
user stories and stuff.
We don't have a requirements tool that we're using, but we are in the process of
evaluating that.
So I'm hoping, you know, this fiscal year we might get a requirements tool to use
for our requirements.
Okay?
Um.
All right.
So back, um, can you give me explain the difference between what a use case is
and a user story?
Sure.
So a use case is more like, um, the description of a functionality from an end
user perspective.
So it would have use cases are more in terms of scenarios.
So it would have a use case name and have a use case number to identify who
the actor is.
You'll have a use case story.
You'll have a trigger to the use case, you'll have a precondition and
postcondition.
And then comes the three flows, three different kind of flows, the primary flow,
which is a happy
day scenario, which which defines the best way of completing the functionality.
Alternate scenarios.
So any scenarios other than primary flow we have which the functionality can be
completed and an exception
scenario which includes failure scenarios where it's a hard stop and the use case
is not completed.
On the other hand, a user story is more like a tool used in agile development,
which again describes
a feature from an end user perspective, but it describes in the form it's a
different format wherein this is a So again, we are identifying the actor, the role
of the user.
I want to. So you're defining what the goal is and then so that it defines the, the
business benefit of, of achieving
that, that enhancement or that particular feature. And then comes acceptance
criteria as to how would you realize in the system to to make it happen.
So.
All right, great.
And your acceptance criteria.,Is there a specific format that you guys typically
write that in or do you just bullet bullet it out
or not?
I like to write my acceptance criteria more as if what are the things that a tester
would need to test
the application?
So not necessarily in terms of test case steps, but so for example, let's say if I'm
if I'm if I'm
if I'm adding let's say if I if I'm adding two fields on on a page, then first of all, I
would say
what is the what page this fields are displayed.
Number two, what are the names of the field?
Number three, it's a text box.
I'll define It's a text box or a radio button or a checkbox or a dropdown, whether
they're required
fields or not.
The content of the field in terms of if it's a drop down, what are the different
options in there,
the sort order of the options, any default selections or not, and then any
validations on submitting
the form.
And I'll also attach a screenshot or a wireframe, a wireframe along with that, just
to have a visual
understanding of how it would look like.
So okay, what do you what type of software do you use to create your
wireframes?
I mean, the old and dirty software, which everyone has, is Visio, which is the last
resort.
However, I'm also familiar with Azure, and to me I'm in love with Azure.
But not every client has it because it comes with a cost, because in Azure you do
awesome because you have it.
I personally haven't used it that much because I just I just haven't had the need.
I've, you know, the stuff I've been doing, I just use Visio as much easier than me
just trying to
go learn it.
Sure.
But I do know that there are teams that, that utilize that.
So yeah, my biggest, my biggest reason I love it is I can do annotations in the
wireframe so I could tag my UI requirements along with that.
And it gives a number to the UI element along with it spits out a nice table when
I generate a report.
So it's more like it creates a UI specification rather than just creating a
wireframe.
So.
Good deal.
All right, let's see.
You mentioned UML diagrams.
Can you kind of describe your experience with those?
Which ones you use and like the purpose for using them?
Right.
So I've used mainly three different set of diagrams.
First is a use case diagram.
So for example, when I'm using when I'm having a use case approach, I might
want to identify, create
an inventory of what are the use cases, who are the actors.
It defines that I might want to show relationships between use cases as to what
use case includes,
which use case or what is an extension to what use case.
So it gives a visual picture.
So to me UML diagrams are more like deserts, which are not needed but always
helpful.
So it helps give a better perspective to the actual requirements.
I've I'm a big, big fan of activity diagrams, irrespective of what I'm doing.
The developers or the business.
If I create a flow the to be process, it's very easy for them to understand before
digging in into
the details of the actual requirements.
Sometimes depending on what kind of diagram I am, depending on the
complexity of a diagram, I might
end up creating Swimlanes just to segregate different actors or different roles
within the diagram.
And very rarely at times I felt the need of using the state diagram.
For example, if there are different states to an account under different scenarios,
I would create
an activity diagram to reflect them just to help the developers and testers
understand the difference
between different states and what leads one state to the other.
So these are the three diagrams I'm familiar with.
All right.
This, I think, will be a simple question for you.
So don't let's see.
Stumped when I when I ask you this.
Let's see.
Um, when you are creating an activity diagram, what symbol would you use to
indicate like a decision
point?
It's called the decision box, right?
I mean, in Visio there's a diamond shaped box.
Yes.
So.
So that's, that's why I was looking for just making a simple question.
I don't want sometimes I ask that question, people are like they overthink it.
Oh okay.
So that's it.
What else.
What else?
The skills of a bar to keep it simple and stupid.
So we try, but sometimes we're we don't get it that get it there.
Sometimes when we describe things that we think are simple, people will read it
and be like, What?
Uh, okay.
Um, can you describe your most complex project and what, and what made it
complex for you?
Um, I would say one of the complex project I worked on was I was working with
that was complex in terms
of, uh, what happened with Discover is they had different businesses within
Discover.
I mean, every company has different business line of businesses within the main
company.
However, the thing which made it a little bit complex was each particular team
was known as a track and they would use a certain piece of code or data.
So if any changes had to be made, it had to route through them.
So for example, if if I'm getting a change, if I have a if you're creating an
application which would
which would display the amount of bill, the bill, the total bill amount outstanding
amount the previous transaction, if or if I would need to have a new date, a new
piece of data to be displayed.
And if that piece of data is owned by billing team, I need to make sure that I
route.
Once I get that requirement from the business, I have to route it to the right
team.
Now, initially when I joined the project was in a chaos.
I was replacing a BA and I got quite a few requirements and someone might have
told me initially that
this is the route, but I was just overwhelmed in the beginning as to what was
going on, and I totally
never paid attention or just a moment of mindedness that I missed.
I thought that I just document the requirements and just pass it on to the
developers.
And there's the one central location where people do the coding.
Later on, after a few weeks and after I missed the deadline, I found that that
wasn't the right approach.
And they had a three month cycle and they were using a straight waterfall with
three month cycles.
So once I missed the deadline, it means that I would only get that requirement
after three months.
So I had a pretty tough time over there.
Initially because I made a fool of myself and I'm just thankful to people around
that.
They gave me the benefit of doubt.
And the next thing I realized is conducting weekly meetings with the leads of all
the different tracks
just for my project.
Initially, I found some resistance and people joining and wasting the 30 minutes
out of their eight
hours.
But slowly, it's all about creating relationship and letting them know as to what
problems can arise
if they miss out on that.
So after a few weeks, people understood that.
And and again, personal relationship helps as well.
People started knowing me and life became much more easier.
So I believe a tougher projects are more because of indiscipline from one and or
because of hard people
working around rather than actually requirements being tough themselves.
They are never tough.
It's just people or the environment that make it tough to realize.
So.
Right?
Right.
That was a good one.
Um.
I just have one more question before I want to look at you have a couple of
questions about your resume.
Um, there are a lot of VA's out there.
I think there's a lot of good VA's out there, but there are certain skills and
qualities, um, that.
You come to expect from an excellent bar?
In your opinion, how would you describe the skills and qualities that you think an
excellent bar has as opposed to just a good bar?
An excellent bar to me is someone who owns the business in terms of, I would
say, someone as an excellent ba who thinks that I myself am a subject matter
expert, not trying, not being arrogant about it, but someone who who is
accountable to the entire project or to or someone who owns the requirements
versus an average or a good bar.
If someone asks a question which is which for which you need to think something
or which is out of the box, they say, Oh, you know what?
It's a good question.
Let me go and talk to the SMEs and get back to you.
So they have to do back and forth, back and forth a few times to get the right
answer versus an excellent
business would understand the bigger picture, would understand what the goals
are, and would try to
fill in the shoes of SMEs themselves so that the SMEs do the work and they can
take care of the project
and they can own the requirements.
Another another difference.
One more difference, and I'll shut up on this.
No, no, no.
That's good.
Another difference is someone who is not an excellent someone who is not afraid
to say, you know what, I don't know that.
Please explain me.
Versus an average says, you know what, I don't need to know for now.
I'll I'll I'll come back to this if the need arises.
So.
Okay.
Good answer.
All right.
I was looking at your resume.
Are you currently working somewhere or are you?
No, I'm currently looking for a new position.
Okay.
Um.
I answered that question about functioning as product owner.
Let's see what other things I had written on here.
Um, traceability matrix.
Can you kind of just describe to me how you manage traceability on projects?
Yep.
I love my old and conventional friend Excel spreadsheet.
That's how I manage.
That's my only resort.
So basically I do mappings.
For example, if I'm if I'm getting a bid which defines the business requirements, I
would do a mapping as to for this business requirement.
These are my business rules.
These are my functional requirements, these are my UI requirements.
If I'm if I'm creating a use cases on top of it, I'm going to tag those rules and
requirements to the
use cases just to ensure that none of the rules or none of the requirements are
orphan and they're all addressed in the flow of a use case.
And then later on, I mean, the developers will do their own technical design
traceability and the
testers will do their own traceability.
But this is what I'll be doing from my end.
Okay.
All right.
Well, that is all the questions I had.
Um, do you have specific questions for me?
Yes.
So the first and the foremost question is you are a manager of the team.
You know, the clients whom you work with.
So looking at my experience, at my background, if I if I'm given an opportunity to
work with your
team, what are some of the challenges which you think I can face upfront in my
earlier days or later
days and something which I need to be careful about this.
This interview is or this position is for our partner track application.
So it's an existing application and you'll be filling in for, um, somebody who's
going out on maternity leave.
But we also are looking for someone who might be willing to stay on after that
kind of contract to hire position.
I am not personally familiar with that project, but from my perspective I would
say since it is an
application that has been it's been around for a couple of years, I think one of the
hardest things
to do is, is when you join a team is just really getting familiar with the domain
knowledge and um,you know, learning the team dynamics.
So it's, you know, kind of like, you know, jumping in where everyone's already
been there.
So it's just that, you know, getting up to speed on, you know, what's currently
going on and.
So.
Okay.
Another question.
Yep.
That answers my question.
You asked me about traceability, so I'm always curious because different people
or different managers, they have their own ways of own versions of managing
traceability.
So what's your idea of traceability in terms of how would you like to manage it in
an ideal world?
It's always a tough one, especially in Agile, in my opinion.
Um, you know, back in the Waterfall days, it's kind of it was easier when you did
everything up front and you're like, you have all your requirements and you have
your use cases and it's all there.
I have a difficult time with it, I'll be honest.
I think that's one of the reasons why we're trying to look for like, a requirements
tool for us.
Um, because, you know, for me.
I actually work on a product development post-production support project, so a
lot of my stuff is already.
It's been products I've actually been owning for years now.
So it's short little user stories.
It's very agile for what I'm doing right now and it's, you know, doing a little bit of
enhancements
and a little bit of bug fixes.
So it's not like huge traceability that I have to worry about because there's such
small little pieces
that get done each time.
So, you know, an agile, I mean, it's to me, it's difficult to manage the traceability.
I mean, I was I was asked this question before in the interview as to how do you
manage traceability
in Agile.
And I said, I've never done that.
And now when you're talking about it, it makes me realize one thing.
So what happens currently with the tool I use is we have features and in features
we come up with user
stories.
So, so at the end of the day, the traceability is that all your user, all your user
stories are delivered
to the business and in a complete status, which changes the status of that
feature to complete.
I think that's about it, right?
In Agile, as far as all I can do and it's all in TFS, I mean and I have, I have the
epics with or
I guess you'd have this new feature level in there that you can utilize to and all
the PBIs tied to
it with all the acceptance criteria and know, in my opinion, if that acceptance
criteria has been
met, you know you have all your testing tasks, your development tasks.
I mean, it's all there.
I mean, and that's I mean, I asked they ask us to ask about the traceability
because, um.
I personally have never seen an agile world people doing traceability matrix.
Exactly, exactly.
And I was asked this question beforehand and I was just shocked.
Shocked, meaning shocked because I had never done that.
So I asked, because you have it on your resume.
Yes.
You had maintained traceability matrix.
But I was just curious on.
No, no, no, no.
But not in Agile.
That's what I meant.
So I was asked this question when I had my first screening for this interview, I
was asked this question as to how do I manage traceability in Agile.
And I said I had no I had no answer to that as to because there's nothing much I
can do.
In Agile, you have features, you have user stories and sometimes you have an
epic which you have 3
to 4 user stories for and you complete those user stories and Epic gets
completed.
So okay, I think those were my questions.
Anything else I can answer for you?
No, I think that I really enjoyed this interview and I think you definitely it was
your knowledge.
Um, so as far as next steps go, I'll be giving my feedback today and I would
expect that they would
be setting up a face to face in the coming, coming days.
Um, all right.
Well, I appreciate it.
And you have a great day.
You too.
And have a good weekend.
All right.
Thank you.
Bye bye.
Bye.