4.1: Agile Requirements Elicitation and Iterative Delivery - Video Tutorials & Practice Problems

<v ->Welcome to lesson four.</v> Now let us talk about Agile requirements elicitation and iterative delivery. So first let us start with the definition of a requirement. According to the International Organization for Standardization or ISO, a requirement is a statement which translates or expresses a need and is associated with constraints or conditions. This statement is written in a language could be a natural language, or a mono language. If expressed in the form of a natural language, the statement should comprise of a subject, a verb and a compliment. A requirement shall state the subject of the requirement could be a system, could be software, could be a product. And what exactly should it do. When you have poorly defined or inadequate or inaccurate incomplete ambiguous requirements. All of this becomes a major cause of poor quality product. The goal of requirements is to describe the capabilities features and the constraints of your product. Requirements contain information on how the product works, how users interact with the product. And most importantly, what customer problem it solves. Requirements format, elicitation techniques, documentation, and any approvals and sign offs differ drastically among the organizations. There are two major principles that drive requirements definition in Agile. First, as we know, Agile teams deliver incrementally. They start with the minimum viable product, or the minimal functionality that provides value to the customer. And then they add features in the order of their priority. They deliver frequently and in short iterations. It accomplishes the goal of delivering value to the customers as early as possible. Now, the second principle. The customer or the user become co-creators of this process. As we saw in lesson three, this collaboration starts before the product is even envisioned. Through hypothesis, validation of those hypothesis. All of it is done in collaboration with customers. And then it continues through the ongoing feedback loop. This feedback loop allows them to learn from the customer, and then final redefine for the requirements. As you see, Agile allows refining requirements to meet user needs throughout all the product delivery. In Agile, requirements elicitation does not happen because the product defined and before the development starts. It's an ongoing process. And it is done in full collaboration with the business, the customer, and the end user. So let us use this opportunity to describe a difference between end user and the customer. As you may recall from lesson three, the end user is the ultimate user of the product. And your customer could be a reseller or a solution provider. So for you, it is really important to focus requirement elicitation on the needs of your end user. And if you do not meet those needs, the reseller or the solution provider would not be in business either. So that's a very logical approach. Always focus on the end user. So now let's talk about the format for this requirement. The way it is represented in Agile. What you see on your screen is a user story. User stories are short, simple descriptions of a feature, told from perspective of the actor who is your end user. Each user story expresses one, just one very specific need that your user has. It can be viewed as a minimum requirement, focused on user needs. User stories. I used an Agile development process to describe product features. They allow developers to focus on what your user needs. The best user stories are based on user research and market analysis. They aren't made up. They reflect actual user needs. Those stories follow a standard format, role, action, benefit. Or who, what and why. It is important to keep in mind the following good practices. The role or who represents a user type. It has to be as specific as possible. The system can be a role, but the development team or product manager cannot design the system for their own benefit. Only for the end user. The second is the action, or what. It describes the system behavior. It's usually unique for every user story. Actions are usually written in active voice. By a needs to purchase a book, versus a book needs to be purchased. The third is the reason or benefit, or the why. It has to be very specific. Otherwise the question arises why this feature is being developed at all. Multiple user stories may share one and the same benefit. The benefit may be for other users or customers, not only for the user of each particular story. The three C's are an important characteristic of a user story. It allows keeping the purpose of the user story in perspective. The 3 C, letter C model was proposed by Ron Jeffries in 2001. The three C's include the following. The first C is the card, which stands for an index card. The concept is that the whole story has to be small, concise, or fit into a single index card. The second C is the conversation. Conversations represent discussions between the project team, customers, relevant stakeholders, and business subject matter experts. In this conversation, stakeholders or team members exchange thoughts, opinions, and suggestions. While the conversation is largely verbal, it can be done in a digital form. For example, as a distributed team, you may communicate via a chat like Slack. Or this may be supported with documentation or within requirements management tools and so forth. The third C is confirmation. A user story is just the start of a conversation. Once the need is articulated, the team raises a lot of questions. They discuss the questions with the end users and then they come up with the best solution. The goal is to build a shared understanding. Here you can find three examples of user stories. Each of them has an actor, an action, and a benefit. Let's review them. As an online book shopper, I want to view details of the book in an online store, so that I make an informed decision. The second one. As a mortgage provider, I want to view the requesters credit score so that I can approve or decline their mortgage based on the risk associated with it. Third one. As a service provider, I want to authenticate my customers so that I provide personalized service based on this subscription type. Look at those again. Each of them has a very clear actor, online book shopper, mortgage provider, or service provider. Each of them has a very clear benefit. Your details of the book. Review the requester's credit score to inform the decision. Or authenticate my customer. And the goal is very clear. Make a decision on purchasing the book. Make a decision of approving the mortgage. Or the third one, provide the service based on this subscription type. So that's what a user story is. A discrete, very simple and very clear requirement.