Scrum Framework Scrum is the type of Agile

Scrum Framework • Scrum is the type of Agile framework. • A framework within which people can address complex adaptive problem while productivity and creativity of delivering product is at highest possible values. • Scrum uses Iterative process. Ajith G. S: poposir. orgfree. com

Scrum Framework • • • Features of Scrum are: Scrum is light‐weighted framework Scrum emphasizes self‐organization Scrum is simple to understand Scrum framework help the team to work together Ajith G. S: poposir. orgfree. com

Scrum Framework Lifecycle of Scrum • Lifecycle of Scrum: Ajith G. S: poposir. orgfree. com

Scrum Framework Lifecycle of Scrum • Sprint: • A Sprint is a time‐box of one month or less. A new Sprint starts immediately after the completion of the previous Sprint. • Release: • When the product is completed then it goes to the Release stage. • Sprint Review: Review • If the product still have some non‐achievable features then it will be checked in this stage and then the product is passed to the Sprint Retrospective stage. • Sprint Retrospective: • In this stage quality or status of the product is checked. Ajith G. S: poposir. orgfree. com

Scrum Framework Lifecycle of Scrum • Product Backlog: • According to the prioritize features the product is organized. • Sprint Backlog: • Sprint Backlog is divided into two parts Product assigned features to sprint and Sprint planning meeting. Ajith G. S: poposir. orgfree. com

Scrum Framework Advantage of using Scrum framework: Scrum framework is fast moving and money efficient. Scrum frameworks by dividing the large product into small sub‐products. • In Scrum customer satisfaction is very important. • Scrum is adaptive in nature because it have short sprint. • As Scrum framework rely on constant feedback therefore the quality of product increases in less amount of time • • • Ajith G. S: poposir. orgfree. com

Scrum Framework Disadvantage of using Scrum framework: Scrum framework do not allow changes into their sprint. Scrum framework is not fully described model. It can be difficult for the Scrum to plan, structure and organize a project that lacks a clear definition. • The daily Scrum meetings and frequent reviews require substantial resources. • • Ajith G. S: poposir. orgfree. com

Scrum Roles • Scrum development efforts consist of one or more Scrum teams, each made up of three Scrum roles: • Product owner, • Scrum. Master, and • the Development team. Ajith G. S: poposir. orgfree. com

Scrum Roles Product Owner is the empowered central point of product leadership is the only authority responsible for what will be developed and in what order • he maintains and communicates to all other participants a clear vision of what the Scrum team is trying to achieve • as such, the product owner is responsible for the overall success of the solution being developed or maintained. • • • Ajith G. S: poposir. orgfree. com

Scrum Roles • Scrum. Master • helps everyone involved understand embrace the Scrum values, principles, and practices • acts as a coach, providing development process leadership • as a facilitator, Scrum. Master helps the team resolve issues and make improvements to its use of Scrum • is responsible for protecting the team from outside interference • takes a leadership role in removing impediments that inhibit team productivity • has no authority to exert control over the team, so this role is not the same as the traditional role of project manager or development manager. The Scrum‐Master functions as a leader, not a manager. Ajith G. S: poposir. orgfree. com

Scrum Roles • Development Team • Traditional software development consists of various job types, such as architect, programmer, tester, database administrator, UI designer, etc. • Scrum defines a development team as a diverse, cross‐functional collection of people who are responsible for designing, building, and testing the desired product. • the development team self‐organizes to determine the best way to accomplish the goal set out by the product owner • is typically five to nine people in size; its members must collectively have all skills needed to produce good quality, working software. Ajith G. S: poposir. orgfree. com

Product Backlog • Using Scrum, we always do the most valuable work first. • The product owner is responsible for determining and managing the sequence of this work and communicating it in the form of a prioritized (or ordered) list known as the product backlog. • On new‐product development the product backlog items initially are features required to meet the product owner’s vision. • For ongoing product development, the product backlog might also contain new features, changes to existing features, defects, needing repair, technical improvements, etc. Ajith G. S: poposir. orgfree. com

Product Backlog • The product owner collaborates with internal and external stakeholders to gather and define the product backlog items. He then ensures that product backlog items Scrum Activities and Artifacts are placed in the correct sequence. Items can be added, deleted, and revised by the product owner as business conditions change. • Overall the activity of creating and refining product backlog items, estimating them, and prioritizing them is known as grooming. • Size equates to cost, and product owners need to know an item’s cost to properly determine its priority. In practice, many teams use a relative size measure such as story points or ideal days. Ajith G. S: poposir. orgfree. com

Sprints • In Scrum, work is performed in iterations or cycles of up to a calendar month called sprints. The work completed in each sprint should create something of tangible value to the customer or user. • Sprints are timeboxed so they always have a fixed start and end date, and generally they should all be of the same duration. Ajith G. S: poposir. orgfree. com

Sprints Sprint Planning • A product backlog may represent many weeks or months of work, which is much more than can be completed in a single, short sprint. To determine the most important subset of product backlog items to build in the next sprint, the product owner, development team, and Scrum. Master perform sprint planning. • During sprint planning, the product owner and development team agree on a sprint goal that defines what the upcoming sprint is supposed to achieve. Using this goal, the development team reviews the product backlog and determines the high priority items that the team can realistically accomplish in the upcoming sprint while working at a sustainable pace. Ajith G. S: poposir. orgfree. com

Sprints Sprint Planning • To acquire confidence in what it can get done, many development teams break down each targeted feature into a set of tasks. The collection of these tasks, along with their associated product backlog items, forms a second backlog called the sprint backlog. • The development team then provides an estimate (typically in hours) of the effort required to complete each task. Ajith G. S: poposir. orgfree. com

Project Velocity • A project’s velocity represents the amount of work the team can perform during a sprint. • To calculate the velocity during a sprint, simply add up the number of features the sprint delivered. • To calculate the number of features, can use story points, points backlog items, items or any other measure that you find useful. Ajith G. S: poposir. orgfree. com

Project Velocity • For example, suppose a team implements 12 story points during a sprint. • Then the velocity during that sprint is 12. • Usually, after a few sprints the team’s velocity becomes relatively stable and you can use it to estimate how much work future sprints can accomplish Ajith G. S: poposir. orgfree. com

Story Points • A story point is an abstract measure of effort required to implement a user story. • It is a number that tells the team about the difficulty level of the story. • Difficulty could be related to complexities, risks, and efforts involved. • In most cases a story point uses one of the following scales for sizing: 1, 2, 4, 8, 16 • X‐Small, Medium, Large, Extra‐Large (“T‐Shirt Sizing”) • Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21 Ajith G. S: poposir. orgfree. com

Story Points • Each team would have to find a baseline story • It does not necessarily to be the smallest one, but the one that everyone within the team can resonate with. • Once determined, sizing of all the user stories should be initiated by comparing them against the baseline. • Assign a point value to each story. • A story that is assigned 2 story points should be twice as much as a story that is assigned 1 story point. Ajith G. S: poposir. orgfree. com

Story Points • Sizing • Gives an overview of the scope of work • Uses multiple perspectives to determine the size of work • Clears out that we can’t be exact • Rectifies false assumptions Ajith G. S: poposir. orgfree. com

Story Points • Sizing • For eg. consider a task of traveling from Delhi to Mumbai. • The duration of the travel depends on the mode of transport (Think mode of transport as the technology with Flight taking 2 hours and Car 22 hours). • If you choose to travel by the road, your driver’s route knowledge (domain knowledge) is required to reach on time. • Duration is dependent on multiple factors, • But the distance is approx 1400 Kms which is constant and doesn’t change. • Now, replace the distance with size. • Size is easy to estimate, but not the duration. Ajith G. S: poposir. orgfree. com

Story Points • • • Sizing The amount of work to do The complexity of the work Risk or uncertainty in doing the work Time / Duration An estimate of effort/duration isn’t possible in Agile, unlike traditional projects. This is because the duration is dependent upon: – Technology / Tools – Domain Knowledge – Skill‐set [technical expertise] of developers doing the work Ajith G. S: poposir. orgfree. com

Story Points Sizing Relative sizing process: 1. List all the stories to be sized 2. Put them in order from smallest to largest – Take the first user story – Then take the second user story – Decide which is bigger and put the bigger one above – Then take the next one and decide where it fits relatively to the other two • – Then take the next one and do the same • – Repeat the process until all the stories are now in the list (in a sequence from smallest to largest) • • Ajith G. S: poposir. orgfree. com

Story Points • • • Sizing Relative sizing process: 3. Size the stories – Start from the bottom and give that story a number 2 story points. Giving ‘ 2’ provides you the room to give a smaller story ‘ 1’ if discovered at a later stage. – Look at the next story and decide how big is that story as compared to the first one – Continue until you have a size on each story – Use these set of numbers [influenced by Fibonacci] while sizing: 1, 2, 3, 5, 8, 13, 21 Note: ‐ we can use T‐shirt sizes XS = 1, S = 2, M = 5, L = 13 , XL = 20, XXL = 40 Ajith G. S: poposir. orgfree. com

Story Points • A story point is a high‐level estimation of complexity involved in the user stories, usually done before sprint planning, during release planning or at a pre‐planning phase. • Story points along with sprint velocity provide a guideline about the stories to be completed in the coming sprints. • The hour based estimation, on the other hand, is a low‐level estimation used to represent the actual effort in man hours needed to complete all the tasks involved in a user story. • Hour based estimation should be used when the task estimations are provided in hours. Ajith G. S: poposir. orgfree. com

Story Points • In fact, story points and task hours serve different purposes at different times and we should avoid relating them to one another for better execution of the sprint and the release. • As the diagram below illustrates, we would recommend not emphasizing on the story points during sprint planning and focus more on estimating the time needed to complete all the tasks involved in the user story. Ajith G. S: poposir. orgfree. com

Story Points • Sizing Ajith G. S: poposir. orgfree. com

Agile Estimation • ‘Story Point’ is the measure of size (or complexity) of user stories in agile projects • ‘Ideal Days’ is the measure of effort in agile projects, which is the number of days a task will take if one person does that task without any interruptions • ‘Velocity’ is the sum of story points delivered by a team per cycle of iteration (sprint) • Two commonly used estimation techniques for agile projects are: • Delphi Wideband • Planning Poker Ajith G. S: poposir. orgfree. com

Planning Game • In Scrum, planning poker (also called Scrum poker ) is a game, can play to decide how much work a particular task might be. • Each team member gets a deck of cards with values based roughly on the Fibonacci sequence. • In that sequence, each number is the sum of the two previous numbers: 0, 1, 1, 2, 3, 5, 8, 13, 21, etc. • Some decks also include a question mark card to indicate that an item will take an unknown amount of time and • a coffee cup card to indicate that you need a break Ajith G. S: poposir. orgfree. com

Planning Game • After everyone has a card deck, the game begins. • The meeting moderator, moderator who normally doesn’t play the game, reads a user story and then leads a brief discussion of restrictions, risks, and assumptions. (Some teams use an egg timer to ensure that the team doesn’t spend too much time on any single story. ) • The players select cards from their decks and place them face‐down on the table. • When everyone is ready, they turn their cards over simultaneously. Ajith G. S: poposir. orgfree. com

Planning Game • Having the players turn their cards over at the same time helps prevent anchoring , a phenomenon in g which early decisions anchor later decisions. • For example, suppose you’re trying to decide whether you want to assign a task a 2 or 3, but then another team member plays a 34 • You might decide you grossly underestimated the task and decide to bump up to an 8. • Playing your cards at the same time gets more honest estimates from everyone. Ajith G. S: poposir. orgfree. com

Planning Game • After everyone plays a card, the people with the highest and lowest estimates are given a soapbox to explain why they feel their estimate is correct. • Who knows? The guy who played a 34 when everyone else played 2 or 3 might know something that everyone else doesn’t. • After the soapboxing, gather up your cards and do it again. • repeat the process until the group reaches a consensus for that item. • Write down the number of points for that story (called its number of story points ) and move on to the next item Ajith G. S: poposir. orgfree. com

User Story • A user story is a tool used in Agile software development to capture a description of a software feature from an end‐user perspective. • A user story describes the type of user, what they want and why. • A user story helps to create a simplified description of a requirement. • All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality Ajith G. S: poposir. orgfree. com

User Story • Format of user stories: It is actually the format of [Who][What][Why] part is optional but it is better to describe that example: As a loan applicant I want to track the status of my loan online • As a user, I want to upload photos so that I can share photos • • Ajith G. S: poposir. orgfree. com

User Story • • • INVEST The acronym INVEST helps to assess the quality of a user story. If the story fails to meet one of these criteria, criteria the team may want to rewrite A good user story should be ‐ INVEST: INVEST Independent: Independent Should be self‐contained in a way that allows to be released without depending on one another. Negotiable: Negotiable Only capture the essence of user's need. User story should not be written like contract. Valuable: Valuable Delivers value to end user. Estimable: Estimable User stories have to able to be estimated so it can be properly prioritized and fit into sprints. Small: Small A user story is a small chunk of work that allows it to be completed in about 3 to 4 days. Testable: Testable A user story has to be tested and verified. Ajith G. S: poposir. orgfree. com

User Story • • Use index cards Write it in simple language Include unique story number Include the priority number Indicate the estimated size in ‘story points’ Easily testable – include acceptance test cases Independent or stand‐alone Include conversations with stakeholders Ajith G. S: poposir. orgfree. com

User Story • Sample Index Card Ajith G. S: poposir. orgfree. com

User Story • Sizing Ajith G. S: poposir. orgfree. com