In this lesson, we are going to learn about the agile approach for doing user

requirements or sometimes we say, "discovering user needs." Before we get into the
agile approach, let's talk about what are good user requirement process would look
like or what would be the outcome if a user requirement process is good. So to me,
I think, if the user requirement process helps you barely work user really need, I
think that would be a good process. So, we know that lot of times users or the
customers, or the clients don't have a clear idea what they want. They cannot
articulate or anticipate what they actually mean. So, a good user requirement
process will help us take what is in their mind and help us build what exactly they
were looking for. And the second aspect would be that it helps build shared
understanding among all the stakeholders of the product. So, whatever the client or
the user had in mind, what they wanted to build, everybody has the same
understanding about what we are trying to build. And if that happens then, at least
we are getting what we wanted to build. In agile approach, this is accomplished by
two key things. One is encouraging conversation and then the second one is to be
adaptive in their requirements. So, making conversation as the primary form of
communication and then allowing the process to discover user needs rather than
collecting all the user needs in one shot. So, let's see how each of these things
play out. So, as far as the conversation is concerned in the agile principles, they
recommends that the developers in the business work together toward the development
process, and it's also recommends face to face communications in between the team
members. So, what that does is that that takes care of one of the issue with the
document-based communication for requirements. So what happens when you use
documents to communicate requirements is that what the user wrote in the document
or what they meant, the architects or the other stakeholders or the developers
understand it differently. What that does is that you build different, to what you
build is something different than what user originally wanted. So, and then an
example of that is the Mars Climate Orbiter. So in that, there was a number in the
requirement that two teams interpreted it differently. So one team interpreted that
number in pounds and the other team interpreted that number in Newtons. So you can
see that although the person who wrote the requirement meant one of those units but
the two teams interpreted it differently and that led to the crashing of this
orbiter. So, does that mean that agile saying no documentation, don't use
documentation for communication? No. In agile approach, we basically take an
approach of Just enough - Just in time and then support it with the conversation.
So, Just enough - Just in time which is also called Progressive Refinement. And
here is how this whole Just in time - Just enough plays out. So, the product owner
or the client, they start with writing lots of cards with a very very high level
functionality of what they want. And then, when the right time comes, when they
pick one of these cards to build the functionality, then they have the second C or
call that conversation where are the business and the developers are coming
together and they are talking about this card they say, "What do you need? Okay, I
understand this. Let's draw. This how we're going to build it. Here is where it's
going to look like." So this rich conversation creates the shared understanding
between the two and also refine the details of the functionality that they want.
And then finally comes the third C which is the confirmation where the two
basically write down what they agreed upon. So once the functionality is done, what
criteria they will use to say that this is actually done? So, this allows them to
conform, have the contract or like a shared understanding that this is exactly what
they'll be build. This is also called the three Cs of user stories. The card, the
conversation and the confirmation. Second part of this agile approach is called the
adaptive where the agile approach accepts that we don't know the needs upfront and
we are going to discover the needs. So in this case, in agile approach, we allow
the requirements to change over time. So what we originally thought, we don't build
exactly the same thing, it changes over time, but whatever we build in the end is
what exactly the user needed because we allow them to change, we allow them to
provide the feedback and change the requirements over time. So, using these two
concepts in creating conversation as a primary form of communication, and being
adaptive, and letting the requirements change, it helps build the shared
understanding among the team members, and it also helps build exactly what the user
was looking for.