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 a 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 build what the user really needs, I think it would be a good process. So, we know that a 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 a 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 the 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, it recommends that the developers in the business work together toward the development process, and it also recommends face-to-face communication between the team members. So, what that does is that that takes care of one of the issues 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 what you build is something different than what the 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 called the conversation where 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 ... this is how we're going to build it. Here is what it's going to look like." So this rich conversation creates the shared understanding between the two and also refines 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 will be built. This is also called the three Cs of user stories. The card, the conversation, and the confirmation. The 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 the 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.
