Hello Welcome back. We will start our discussion on the requirements. We will see how requirements are handled in Scrum. We will start with the basics. In traditional approach the scope is fixed requirements are somewhat fixed in the beginning of the project and we are planning the project based on these requirements. The questions asked will be how long will it take to complete these requirements?
How much will it cost to complete these requirements? in Agile scope varies. Other concerns cost time and quality are fixed. The question will be given this priority, budget and time what scope can be completed. You can't gather all the requirements upfront requirements evolves as development for regresses, we will start with an initial set of requirements. As the project progresses, more will be known and the requirements evolves with the product being built.
Product Backlog exists and gets updated as long as the product exists. This is a live artifact. This is true regarding the estimates as well. As more knowledge is available, we revisit our estimates and make corrections to the plan. We can't do everything first. We deliver it in an iterative and incremental way.
Proper ordering of the backlog items make sure that most valuable items are delivered earlier. prioritization is a key aspect in the backlog management. We deliver in short time boxed cycles. A new high priority item has to wait only for a short period before development to start on it Product vision describes the purpose of a product, the intention with which the product is being created, and what it aims to achieve for customers or users. It describes the purpose of your product, why it is being built? What are the expected benefits, it gives a bigger picture of what we are working on and why the product vision is aligned to the business goals of the organization.
It creates a common understanding among all parties involved. It guides us in making decisions throughout the project. It helps us in keeping the focus on the business goals. We must express it in a simple language. Everyone should understand the purpose. We won't be able to cover all aspects of the product, but it represents in clear words the vision of the product.
This keeps everyone are motivated to work towards achieving the goals or product vision statement must be expressed in a proper format, which is suitable for the product and the industry whether it is placed. A commonly used format is given here. For a target customer who has a need or opportunity, the product is a product in this category that gives these benefits. Unlike competitive product, our product gives an edge or makes a key difference. An example can be for agile enthusiasts who want to be a successful product owner. The product owner training is an online course that teaches the outer product ownership.
Unlike other courses, our product gives the to the point training with less duration and more value. The product backlog is an ordered list of everything that is known to be needed in the product. Usually the items take the form of epics and user stories, Product Owner owns and prioritizes the product backlog. This is a live document. The Product Backlog exists as long as the product exists, items can be added to the product backlog at any time during the project. It is a prioritized list of requirements that provide business value for the customer.
Product Owner is responsible for creating and maintaining requirements. But team can contribute in this activity. team can get involved in this activity with maximum of 10% of their capacity. The final decision on the order of items in the product backlog is from the product owner. However, other roles can influence these decisions. One of the commonly used models is Moscow, where backlog items are categorized As must have, which is a minimum usable subset should have, could have or won't have, we would like in the future.
Other approaches for ordering include those based on business value, risk based, caner model, etc. A product backlog contains different types of items like story based work, task based work, etc. In short everything that is required for the product. Higher ordered product backlog items are usually smaller, clearer and more detailed than lower ordered ones. Product Owner is responsible for maintaining product backlog, but the estimates must come from the people who do the work. The development team is responsible for all estimates.
P p stands for detailed appropriately emergent, estimated, prioritized. We have discussed all these aspects. Product Backlog items must have enough details based on what is known so far. It is a live document, it gets updated throughout the life of the product. It's a prioritized list with an estimate based on what is known. A healthy product backlog will be respecting the deep criteria.
Items will exist at different levels of detail. There will be items that are ready for implementation an items which need further refinement. The list should be prioritized and estimated based on the availability of information. As good practice teams make sure there is enough ready user stories for upcoming and number of Sprint's. This number will be agreed upon by the scrum team. A user story is a requirement written in an end user perspective.
A user story describes functionality that will be valuable to either a user or a purchaser of a system or software. These are written in the perspective of the customer. It reflects what the customer expects from, or wants to do with the product. items in the product backlog are usually written in the form of user stories, it usually takes this form. As a user, I want to do something so that I get this benefit. For example, as a user, I want to see the list of all emails received, so that I can select one for viewing the three C's for a user story, our pod conversation, confirmation card indicates that the user story should be smaller for a single card.
Conversation talks about the detailing part. detailing will be a result of further discussions and collaboration. More details will be attached or added to the user story as we go along. For information indicates when we can confirm that the user story is successfully implemented. Usually it may take the form of the acceptable criteria. Spike is a story or task aimed at answering a question or gathering information.
Rather than producing shippable product. The purpose is to gain the knowledge necessary to reduce the risk of a technical approach. That's an understanding of a requirement or increase the reliability of a story estimate. Larger user stories are typically referred to as epics. epics generally take more than one or two Sprint's to develop in Test. They're usually broad in scope, short on details, and must be split into multiple smaller stories before the team can work on them.
In short, we can say it's a large user story. A theme is a group of user stories that share a common attribute. They are grouped together for convenience. For example, we can have a theme communication. All stories related to customer communication can be grouped and tracked under this themes are often used to organize stories into releases, or to organize them so that various sub teams can work on them. A good user story should follow invest, it stands for independent, negotiable, valuable, estimable, sized appropriately and testable, independent implies the user story should be Be self contained in a way that there is no inherent dependency and another user story.
It should be negotiable. Stories are not contracts leave room for discussions. More details will be added or it changes as more knowledge is available. The user story should be valuable to customers and users, not developers, it should be written to reflect a user or client perspective. A user story must have enough details to estimate a required levels. predictions are based on these estimates, so we should be able to estimate them.
A user story must be small enough to complete in one sprint. Large stories should be split into smaller ones. A user story must be testable. The confirmation attribute that we have discussed earlier must be stated clearly. The user stories should be small enough to be implemented within one sprint. But it is up to the scrum team to decide what extent the stories should be fine grained.
Based on the nature of work. And epic, in general, can be considered as a large user story that needs to be broken down to smaller user stories. Scrum teams will decide to what extent the story should be fine grained. Based on the nature of work. Maybe we can consider an epic as ready when all user stories derived from it already. acceptance criteria is a set of pre established conditions that the product increment to satisfy to be accepted by the user.
It is also known as conditions of satisfaction And will be provided by product owner. It can include functional and non functional elements. It should be expressed in simple language without leaving room for any ambiguity. acceptance criteria is written in simple language defines the conditions of success or conditions of satisfaction. It provides clear story boundaries. acceptance criteria removes ambiguity by forcing the team to think through how a feature or a piece of functionality will work from the users perspective.
It provides a checklist or template of things to consider for each story and establishes the basis for acceptance testing. Instead of a simple user story, as an admin, I want to create users so that I can grant access to the system acceptance criteria for User Story can include items like an admin can create user accounts. No other role is able to create users. an admin can create user with user name, email id, mobile number, system displays a message or any of the above fields are missing and use it is not created. system sends an email to the user once the account is created, the list can go on. Definition of ready for a user story confirms that the user story is ready for implementation.
This can include items like story defined and the business value is clearly articulated. story has been assigned with the right amount of story points. It is estimated is clearly understood by the development team. acceptance criteria are clear and testable dependencies identified and no external dependencies will block the story from being completed. Business test dates are required to test the story has been identified. performance criteria if any, are defined and measurable.
The story is small enough to be comfortably completed in one sprint. Definition of done for a user story is a set of pre established conditions for confirming the same as done. It is not the same as acceptance criteria, but meeting the acceptance criteria will be an automatic selection to the list. It considers many aspects Like organizational processes, standards, legal requirements etc. It is agreed upon the development team and the product owner. It will be inspected in regular intervals and improved it is not a frozen document it can be defined for sprint and release as well.
Checklists confirming if the sprint or release is done in all aspects. Considered a simple user story. As an admin, I want to create users so that I can grant access to the system. items and a definition of done can include user story meet acceptance criteria, and reviewed by the product owner. All code changes are reviewed as prescribed. A quality manual and major findings are closed.
Code changes are checked to Xyz Zed branch, the list can go on Definition of done for a sprint confirms that all required tasks and other activities for the sprint are completed. It can include but not limited to, definition of done of each single user story. Included in the sprint I met or unit test passing. Product Backlog is updated product increment is deployed on a test environment identical to production platform. The performance tests passed all category one bugs are fixed. Completed user stories are accepted by the product owner.
These are a few examples that can be more or less items depending on the nature of the project. Definition of done God for release confirms that all required tasks and other activities for the release are completed. can include but not limited to code complete reached, environments are ready for release or test results are green. All the acceptance criteria are met, QA is done and all issues resolved. Green baseline. Now no open issue and build an integration release documents are ready.
These are a few examples that can be more or less items depending on the nature of the project. There are different estimation techniques in use. Traditionally, we use techniques like lines of code, function points, use case points, etc. in Agile we use techniques like story points, t shirt sizing, ideal days, etc. Ideal days is an absolute estimation method. It estimates how long something will take if it's all you work on, and there are no interruptions for the work.
You have everything you need for carrying out the work. In Scrum task level estimates are usually done in ideal hours. Relative estimation consists of estimating something not separately and not in absolute units of time. But in comparison with one another. It is also done by grouping of items of equivalent size. In short estimation is done in relative way in comparison with one another.
T shirt sizing and story points are two examples of relative estimation story points is an arbitrary measure used for Scrum teams is used to measure the effort required to implement a story. It is a relative measure, it is done by comparison. It estimates How long will it take considering many factors like complexity, uncertainty, and risk etc. It is a faster way of estimating people who do the work the development team is responsible for making this estimate. A frequently used scale is the Fibonacci series. story points are a unit of measure for expressing the overall size of the user story, feature or other piece of work.
The number of story points associated with the user story represents the overall size of the story. When estimating with story points, we assign a point value to each of them. The other The characteristics are the estimation scale should be nonlinear. frequently used scale is Fibonacci series etc. We use the sets of numbers that make sense, we may use a modified Fibonacci series as well, like 01235 813 and 2040, etc. Larger stories, epics can have a range like 100 200, etc.
Story pointing is a relative estimation method, it requires a referral point to do the estimates. Experienced teams may have a clear understanding as to what story point is meant for them. This is from their previous story pointing when we do it for the first time we need to create a base a story of a reasonably small size will be selected and assigned one or two points. Other Stories will be compared with this to find it sighs some companies advocate considering certain hours of effort as a story point. This is a controversial approach and against the sense of story pointing. Planning poker is a method tool or an activity for estimating using story points.
Usually it follows the below steps. First, the product owner provides a short overview of the story to be estimated. The team discusses to clarify assumptions and risks and the outcome of the discussion is updated in the user story. Each individual is given a set of cards with the values that are used. Usually the cards are with Fibonacci numbers. Each individual selects the card representing the estimate and lays it down.
Everyone shows that Cards simultaneously by turning them over. If there is a difference, people with high estimates and low estimates are given a chance to clarify their estimate and then the process repeats. What should we do if there is no consensus in planning poker? participate participants with estimate at extreme ends will explain the logic behind the estimation. Product Owner clarifies if there are any points or wrong understanding. Once the story and expect to work is clear, team will estimate again.
This process can repeat but can't go on indefinitely. If the team fails to get an estimate that indicates there is no single shared understanding on the story or the work related to it. The story should be part for further grooming. Pieces shirt sizing is a way of relative sizing by comparing stories you can put them in buckets of extra small, small, medium, large and extra large. Estimating relative buckets is easier than estimating absolute time or effort. estimation is not a one time activity at earliest stages at epic or feature level estimates will be at a high level.
Once requirements reach the level of user stories, we will do a relative estimation with story points while doing the sprint planning. We will create tasks for each story which will be estimated using ideal days or ideal hours.