Hello, welcome back. We will discuss a few approaches for gathering requirements. A few points to note our requirements evolves as development progresses, we will start with high level requirements and improve and expand them throughout the lifetime. This process should be participatory. Remember the three C's that we have discussed as part of user stories. conversation is the key element in detailing the requirements.
Throughout this process, we focus on the business and product goals. Some of the methods used for gathering requirements are briefly discussed in here. This is not a comprehensive list. There's selection of methods depends on the product owner and the environment in which he or she operates. rights user interviews. This is a traditional and common approach in gathering information, define rights set of questions and interview the stakeholders on a one to one basis.
Selection of the right interviewee is important. We must identify the persons with right and no knowledge on the product. He or she should be able to clearly describe the expectations. identify different user roles interacting with the system. Prepare sets of questions for each role, we must define the right set of questions. The question should facilitate the thought process of the interviewee.
Go for an open ended context free questions in the beginning to get a wide perspective of the system. Based on the answers go deep into various areas. prototyping creates a representation of the expected system Along with the stakeholders, this will have a view impact. This can be done using wireframes sticky notes on whiteboard as simple physical modeling, etc. Something in front of their eyes, the participants will be able to come up with more details. They will add no expectation or even remove or D prioritize a few.
Story writing workshops. story writing workshop is one of the best techniques of writing user stories. This is a participatory approach where the right group of people discuss and identify as many user stories as possible. We should keep the focus on identifying the user stories. Avoid this meeting turning into a design or architecture workshop. This technique is very effective and helps him release planning.
There are many other methods that we can use. selection of the methods depends on the nature of the product. Kind of stakeholders and their availability, etc. A few other methods that we can consider can be brainstorming, document analysis, focus group, interface analysis, observation requirements workshop survey. Use a story mapping is a visual representation that helps to define the work that is required in the product. It is a visual way of creating product backlog.
It can be used in finding out the user stories for the product in a structured way. We are approaching this activity from a user perspective. It helps in identifying the user stories and grouping them. The output from this exercise can be used in release planning. Let's discuss this using an example. Consider an application for making hotel reservations.
One of the goals of this product will be a user should be able to book a hotel room online. If we further look into this, there are many activities involved in this process. Searching for hotels is one of them. There are many tasks that the user may perform as part of this activity, like search on date and location, assaults based on price. The filter on user ratings, if we convert them to user stories, there can be many stories like as a user, I want to search based on the date and location so that I see the availability as a user, I want to sort the list on price so that I can select a room. As a user, I want to filter the list on rating so that I can select a room Like this we can analyze a map different features of the product.
This brings in a shared understanding among all parties involved. This helps in breaking down important features of the application. As we have all main stories on the board, doing a relative estimation becomes easier. It helps in prioritization and release planning. We split the stories based on functionality, not based on technical layers, or stories we'll cover all technical layers are required for its implementation. This approach is called slicing the cake.
In other words, we should not split user stories based on architectural layers. It should be done based on functionality. each slice should have a part of all the layers there are different approaches used to break down epics or users Stories, a few of them are listed below. workflow steps business rule variations, major effort, simple or complex split to using crud which is create read update delete operations, variations in data, data entry methods spike first split at basic or exception path, the defer performance. In the coming slides we will see examples for these approaches. Always remember the slicing the cake approach that we have discussed earlier.
We should not split user stories based on architectural layers. It should be done based on functionality. each slice should have a part of all the layers. workflow steps when a user story involves work Some kind, the item can be usually broken down into individual steps. Consider the user story. As a customer, I want to shop online.
So that's our receive my products at home. There are different steps involved in this process, we can split the story based on them. To among the resulting stories can be as a customer, I want to log in to the online stores so that I can shop as a customer. I want to view my shopping cart so that I can do a check out. business rule variations. When a user story contains a process that with different business rules, we can split it based on those rules.
Consider the user story. As a customer I want to pay online. So that's how I received my products at home. There are many concerns in this process, too among the resulting stories can be As a customer, I want to pay using credit card so that I can shop online. As a shop owner, I want to view the payment status so that I can process the order. major effort.
If the user story involves a major functionality and its variations, we will break out the variations and implement the major effort. First, consider the user story. As a customer, I want to pay online with visa, Amex or mastercards. So that's I received my products at home. The major effort here we'll be using the payment infrastructure. Once it is in place, other cards can be added with less effort to among the resulting stories can be as a customer, I want to pay using VISA credit card.
So that's how I can show up online. Once it is implemented. We can extend it As a customer, I want to pay using MasterCard so that I can shop online. simple or complex. Start with a simple implementation and add more functionality later. Consider the user story.
As customer I want to search for hotels so that I can make a booking to among the resulting stories can be as a customer, I want to search with the date and location so that I can do a booking. Once this is in place, we can add more features. As a customer, I want to see options in adjacent dates so that I can see and select the best one. Split using crud. Create read, update delete operations. A user story can be split using different operations such as create, read, update, or delete, consider the user story.
As a customer, I want to create my profile to among the resulting stories can be as a customer, I want to create my profile with basic information name, and email. As a customer, I want to update my profile so that I can add more details. The variations in data, or user story can be split based on the data that the operation uses. Consider the user story. As an online customer, I want to search for laptops so that I can buy them online. To among the resulting stories can be as an online customer, I want to search for laptops with make and price so that I can buy them online.
As an online customer, I want to search for laptops with processor type and RAM. So that's I can buy them online. Data Entry methods and input form can be filled and saved using different ways. The first manual then automated, consider the user story. As a customer, I want to search for hotels, so that I can make a booking. Here we will start with a simple implementation and make fancy user interface later.
To among the resulting stories can be as a customer, I want to search with date and location so that I can do a booking. Now we will enhance the experience. As a customer, I want to select a location using map so that I can search for hotels. Spike first approach when a user story has a complex functionality, challenging technology concerns that the team is unsure about. do an experiment. First, consider the user story.
As a customer, I want to pay online. So that's I received my products at home creates a spike for experimenting with online payment gateways. This will reduce the unknowns regarding the functionality. Great user stories based on the result of this experiment. Split at basic or exception path. Start with a simple implementation and go for exceptional cases, consider the user story.
As a customer, I want to search for hotels so that I can make a booking we will start with a normal simple flow to among the resulting stories can be as a customer, I want to search with date and location. So that's how I can do a booking. Now an advanced feature as a customer, I want the system To identify my current location, if I leave it blank so that I can search for hotels in my location, different performance, make it work then make it fast. Make the functionality work before going for optimization, consider the user story. As a customer, I want to search for hotels so that I can make a booking to among the resulting stories can be as a customer, I want to search with date and location so that I can do a booking. As a customer, I want to see the search results within two seconds so that I can book faster.
There are many other methods use for breaking down user stories, including based on test scenarios or test cases based on roles based on acceptance criteria, and based on external dependencies. etc. Always remember the final decision on the order is from the product owner. However, other roles can influence these decisions. Product Backlog items are ordered to provide maximum benefits to the business by delivering higher value items earlier than later. The factors that influence these decisions are the business value, market demand, team capability, risk, dependencies, etc.
There are different methods that exist for the prioritization or product backlog Mosco analysis. In this method, a list of requirements or user stories are categorized into the following four groups must have describes a recording And that must be satisfied in the final solution for the solution to be considered success should have represents a high priority item that should be included in the solution if it is possible. This is often an important requirement, but one which can be satisfied in other ways, if absolutely necessary, could have describes a requirement which is considered desirable, but not necessary. This will be included if time and resources permit won't have represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered in the future. Poker method This is similar to planning poker. It is a quick and easy method to group items as per their relative priorities.
Categories used here can be a very high priority, high priority medium priority, low priority, very low priority. This steps are similar to that of planning poker. All participants are given cards representing these values. We can use another set of values like high, medium and low. That is prioritizing using only three categories. First, the moderator presents the backlog item to be prioritized.
He clarifies a requirement and each participant selects his or her card. All participants show their selection at the same time. If there are any differences that will be discussed and the process continues. With the feature this is kind of a cumulative bidding method. All participants are given the same amount of money say $100. The aim is to distribute this money among the backlog items.
Under consideration, the moderator introduces all the backlog items to be prioritized. After that, each participant distributes the amount among these items based on his or her take on the priorities. Once this is done, the backlog items are prioritized based on the total amount each item received. There are many other methods used for prioritizing the backlog items. They include methods like Kanan model, stack ranking, weighted shortest job first, which is WSJ F, buy a feature, etc. Whatever be the model used in the final decision on the order is from the product owner.
Planning is done at different levels. In the scrum it all starts with a product division. We will have a high level plan at the release level. Every sprint starts with a sprint planning meeting every day development team collaborates and planned activities for the next 24 hours during daily Scrum. A few more points to note here are planning is not a one time activity. We inspect and adapt the plan as more knowledge is available.
Agile plans are adaptive not predictive, we adapt the plans to the changes, plans will change as more knowledge is available. There will be a high level plan at the release level based on what is known but this is not a frozen contract. This gives an overall view of how the product will evolve across iterations. It is a high level plan for multiple Sprint's this reflects expectations like which features will be implemented and when velocity helps us in refining the release plan. The current size of the product backlog and the velocity will give as the number of iterations required are repeat. This is based on what is known so far.
We have already seen this image, we will add it again for the completion of our discussion. Based on the predictive velocity we can map the stories across different iteration. output from the story mapping exercise priorities and dependencies will play a crucial role in this mapping. This activity can be done as a continuation of the story mapping exercise