Post on 28-Feb-2021
ì Scrum an agile development process methodology
-‐Abhijit Mahajan -‐Neelam Agrawal
Introduction
ì Scrum is an agile so<ware development methodology
ì It is an itera>ve and incremental methodology ì for so<ware projects and product-‐ or applica>on-‐
development
ì Projects progress via a series of itera>ons ì called sprints
ì which are usually 2-‐4 weeks long
ì A typical scrum team has between five and nine people ì but Scrum projects can easily scale into the hundreds
History
History
ì 1993-‐Jeff Sutherland, John Scumniotales and Jeff McKenna, came up with an approach at Easel Corpora>on ì first to refer it using the single word Scrum.
ì In 1996, Sutherland and Schwaber jointly presented a paper describing the Scrum method at the Business Object Design and Implementa>on Workshop ì held as part of OOPSLA ’95 in Aus>n, Texas.
ì 1998-‐ Ken, Jeff, et al came up with “Scrum a pa[ern language for hyperproduc>ve so<ware development”
ì In 2001, Schwaber worked with Mike Beedle to describe the method in the book Agile with Scrum
SCRUM Methodology
Scrum & Rugby
ì The SCRUM methodology shares many characteris>cs with the sport of Rugby : ì The context is set by playing field (environment) and rugby rules (controls). ì The primary cycle is moving the ball forward. ì Rugby evolved from breaking soccer rules -‐ adap>ng to
the environment. ì The game does not end un>l environment dictates
(business need, compe>>on, func>onality, >metable).
Scrum phase list
ì Pregame ì Planning ì System Architecture/High Level Design
ì Game ì Sprints (Concurrent Engineering) ì Develop (Analysis,Design,Develop) ì Wrap ì Review ì Adjust
ì Postgame ì Closure
SCRUM Phases (1)
ì Pregame ì Planning :
ì Defini>on of a new release based on currently known backlog, along with an es>mate of its schedule and cost.
ì If a new system is being developed, this phase consists of both conceptualiza>on and analysis.
ì If an exis>ng system is being enhanced, this phase consists of limited analysis.
ì Architecture : ì Design how the backlog items will be implemented. ì This phase includes system architecture modifica>on and
high level design.
SCRUM Phases (2)
ì Game ì Development Sprints :
ì Development of new release func>onality, with constant respect to the variables of >me, requirements, quality, cost, and compe>>on.
ì Interac>on with these variables defines the end of this phase.
ì There are mul>ple, itera>ve development sprints, or cycles, that are used to evolve the system.
ì Postgame ì Closure :
ì Prepara>on for release, including final documenta>on, pre-‐release staged tes>ng, and release.
Planning (1)
ì Development of a comprehensive backlog list.
ì Defini>on of the delivery date and func>onality of one or more releases.
ì Selec>on of the release most appropriate for immediate development.
ì Mapping of product packets (objects) for backlog items in the selected release.
ì Defini>on of project team(s) for the building of the new release.
Planning (2)
ì Assessment of risk and appropriate risk controls.
ì Review and possible adjustment of backlog items and packets.
ì Valida>on or reselec>on of development tools and infrastructure.
ì Es>ma>on of release cost, including development, collateral material, marke>ng, training, and rollout.
ì Verifica>on of management approval and funding.
Architecture/High Level Design (1)
ì Review assigned backlog items.
ì Iden>fy changes necessary to implement backlog items.
ì Perform domain analysis to the extent required to build, enhance, or update the domain models to reflect the new system context and requirements.
ì Refine the system architecture to support the new context and requirements.
Architecture/High Level Design (2)
ì Iden>fy any problems or issues in developing or implemen>ng the changes
ì Design review mee>ng, each team presen>ng approach and changes to implement each backlog item.
ì Reassign changes as required.
Sprint (1)
ì A sprint is the basic unit in Scrum ì lasts between one week and one month
ì Each sprint is preceded by a mee>ng ì where the tasks for the sprint are ini>ated for the sprint
goal
ì The work items come from the product backlog ì which is a priori>zed list of requirements
ì During the sprint planning mee>ng, the Product Owner informs the group of the items in the product backlog that needs to be completed ì the ones with the highest priority
Sprint (2)
ì The group then determines how much of this they can commit to complete during the next sprint ì and records this in the sprint backlog
ì During a sprint, no one is allowed to change the sprint backlog ì which means that the requirements are frozen for
that sprint ì if requirements are not completed for any reason
they are le< out and returned to the product backlog
More Game phase(1)
ì Develop: ì Defining changes needed for
ì the implementa>on of backlog requirements into packets, opening the packets, performing domain analysis
ì designing, developing, implemen>ng, tes>ng, and documen>ng the changes.
ì Development consists of the micro process of discovery, inven>on, and implementa>on.
ì Wrap: ì Closing the packets, crea>ng an executable version of
changes and how they implement backlog requirements.
More Game phase (2)
ì Review: ì All teams mee>ng to present
ì work and review progress ì raising and resolving issues and problems ì adding new backlog items
ì Risk is reviewed and appropriate responses defined.
ì Adjust: ì Consolida>ng the informa>on gathered from the review
mee>ng into affected packets, including different look and feel and new proper>es.
Closure
ì When the management team feels that the variables of >me, compe>>on, requirements, cost, and quality concur for a new release to occur, they declare the release “closed” and enter this phase.
ì This phase prepares the developed product for general release.
ì Integra>on, system test, user documenta>on, training material prepara>on, and marke>ng material prepara>on are among closure tasks.
Roles
The various roles in Scrum team
ì Core Roles ì Product Owner ì Development Team ì Scrum Master
ì Ancillary roles ì Stakeholders (customers, vendors) ì Managers
Product Owner
ì The Product Owner represents the voice of the customer ì is accountable for ensuring that the Group delivers
value to the business ì Writes customer-‐centric items (user stories),
ì priori>zes them ì and adds them to the product backlog
ì Scrum groups should have one Product Owner ì She may also be a member of the Management Group ì It is recommended that this role not be combined
with ScrumMaster
Development Team
ì Responsible for delivering poten>ally shippable product increments at the end of each Sprint.
ì It is made up of people with cross-‐func>onal skills ì who do the actual work
ì analyze, design, develop, test, technical communica>on, document, etc
ì It is self-‐organizing ì even though they may interface with project
management organiza>ons (PMOs).
Scrum Master
ì Scrum Master is accountable for removing impediments to the ability of the group to deliver the sprint goal/deliverables.
ì She acts as a buffer between the group and any distrac>ng influences.
ì The Scrum Master is the enforcer of rules. ì A key part of the role is to protect the Development
Team and keep it focused on the tasks at hand.
Ancillary Roles
ì The ancillary roles in Scrum groups are those with no formal role and infrequent involvement in the Scrum process ì but nonetheless, must be taken into account.
ì Stakeholders (customers, vendors): ì People who enable the project and for whom the project
produces the agreed-‐upon benefit[s] ì that jus>fy its produc>on
ì They are only directly involved in the process during the sprint reviews
ì Managers: ì People who control the environment
Meetings Overview
Meetings
The following is a list of meeCngs in Scrum development
ì Daily Scrum
ì Backlog grooming: storyCme
ì Scrum of Scrums
ì Sprint planning meeCng
ì Sprint review meeCng
ì Sprint retrospecCve
Daily Scrum (1)
ì Happens each day during the sprint ì is a project status mee>ng
ì This mee>ng has specific guidelines: ì The mee>ng starts precisely on >me ì All are welcome, but normally only the core roles
speak ì The mee>ng length is set to 15 mins ì The mee>ng should happen at the same loca>on
and same >me every day
Daily Scrum (2)
ì During the mee>ng, each group member answers three ques>ons ì What have you done since yesterday? ì What are you planning to do today? ì Any impediments/stumbling blocks?
ì Scrum Master should facilitate resolu>on of these impediments, although the resolu>on should occur outside the Daily Scrum itself to keep it under 15 minutes.
Backlog grooming: storytime
ì This is the process of ì es>ma>ng the exis>ng backlog using effort/points ì refining the acceptance criteria for individual stories ì and breaking larger stories into smaller stories
ì Mee>ngs should not be longer than an hour
ì Mee>ng does not include breaking stories into tasks
ì Group can decide how many mee>ngs are needed per week.
Scrum of scrums
ì Each day normally a<er the Daily Scrum.
ì These mee>ngs allow clusters of groups to discuss their work, focusing especially on areas of overlap and integra>on.
ì A designated person from each group a[ends.
ì The agenda will be the same as the Daily Scrum, plus the following four ques>ons: ì What has your group done since we last met? ì What will your group do before we meet again? ì Is anything slowing your group down or gemng in their way? ì Are you about to put something in another group’s way?
Sprint planning meeting(1)
ì Takes place at the beginning of the sprint cycle
ì The Sprint Planning Mee>ng is a[ended by ì the product owner ì Scrum Master ì the en>re Scrum Team.
ì There are two defined ar>facts resul>ng from this mee>ng: ì A sprint goal ì A sprint backlog
ì A sprint goal is a short, one-‐ or two-‐sentence, descrip>on of what the team plans to achieve during the sprint. ì It is wri[en collabora>vely by the team and the product owner
Sprint planning meeting(2)
ì The team asks enough ques>ons so that they can turn a high-‐level user story of the product backlog into the more detailed tasks of the sprint backlog.
ì Sprint Backlog is prepared with details of the >me it will take to do a par>cular work
ì Iden>fy and communicate how much of the work is likely to be done during the current sprint
ì Eight hour >me limit ì (1st four hours) Product Owner + Group: dialog for
priori>zing the Product Backlog ì (2nd four hours) Group only: hashing out a plan for the
Sprint, resul>ng in the Sprint Backlog
Sprint review meeting(1)
ì Held at the end of each sprint during which the Scrum team shows what they accomplished during the sprint.
ì Typically this takes the form of a demo of the new features.
ì It is inten>onally kept very informal, typically with rules forbidding the use of PowerPoint slides.
ì A sprint review mee>ng should not become a distrac>on or significant detour for the team ì rather, it should be a natural result of the sprint
Sprint review meeting(2)
ì Par>cipants in the sprint review typically include ì the Product Owner ì the Scrum team ì the ScrumMaster ì management, customers, and developers.
ì The project is assessed against the sprint goal determined during the Sprint planning mee>ng.
ì It is important that the team has achieved the overall goal of the sprint.
Sprint Review Meeting (3)
Sprint retrospective
ì The sprint retrospec>ve is usually the last thing done in a sprint. ì Many teams do it immediately a<er the sprint review.
ì This is a period at the end of each sprint to deliberately reflect on how the team is doing and to find ways to improve.
ì The en>re team, including both the ScrumMaster and the product owner par>cipate in this mee>ng.
ì It has three hour >me limit
ì Two main ques>ons asked in the sprint retrospec>ve are: ì What went well during the sprint? ì What could be improved in the next sprint?
Artifacts
ì Product Backlog
ì Sprint Backlog
ì Burndown Charts
Product Backlog(1)
ì It is an ordered list of "requirements” maintained for a product.
ì These items are ordered by the Product Owner based on considera>ons like risk, business value, dependencies, date needed, etc.
ì The values in product backlog are o<en stated in story points using a rounded Fibonacci sequence.
Product Backlog(2)
ì Those es>mates help the Product Owner to gauge the >meline and may influence ordering of backlog items.
ì The Product Backlog, and business value of each listed item is the responsibility of the Product Owner.
ì The es>mated effort to complete each backlog item is determined by the Development Team.
Product Backlog
Sprint Backlog(1)
ì It is the list of work the Development Team must address during the next sprint.
ì The list is derived by selec>ng stories/features from the top of the product backlog.
ì The Development Team should keep in mind the velocity of its previous Sprints when selec>ng stories/features for the new sprint.
Sprint Backlog(2)
ì The stories/features are broken down into tasks by the Development Team ì should normally be between four and sixteen hours of
work
ì Tasks on the sprint backlog are never assigned; ì rather, tasks are signed up for by the group members as
needed during the daily scrum.
ì O<en an accompanying task board is used to see and change the state of the tasks of the current sprint, ì like “not checked out”, “checked out” and “done”.
Sprint Backlog
Burndown Charts
ì Sprint burndown chart ì It is a publicly displayed chart (updated daily)showing
remaining work in the sprint backlog. ì It gives a simple view of the sprint progress.
ì Release burndown chart ì shows the amount of work le< to complete the target
commitment for a Product Release
ì Alterna>ve release burndown chart ì which basically does the same, but clearly shows scope
changes to Release Content, by resemng the baseline.
Burndown Charts
Modifications: Scrum-‐ban(1)
ì Scrum-‐ban is a produc>on model based on Scrum and Kanban.
ì It is suited for maintenance projects or (system) projects with frequent and unexpected user stories or programming errors.
ì In such cases the >me-‐limited sprints of the Scrum model are of no appreciable use, but Scrum’s daily mee>ngs and other prac>ces can be applied.
ì Visualiza>on of the work stages and limita>ons for simultaneous unfinished user stories and defects are familiar from the Kanban model.
Modifications: Scrum-‐ban(2)
ì Using these methods, the group’s workflow is directed in a way ì that allows for minimum comple>on >me for each user
story or programming error, ì and on the other hand ensures each group member is
constantly employed.
ì The major differences between Scrum and Kanban are ì in Scrum, work is divided into sprints that last a certain
amount of >me ì whereas in Kanban the workflow is con>nuous.
Advantages (1)
ì The SCRUM methodology is designed to be quite flexible throughout.
ì It provides control mechanisms for planning a product release and then managing variables as the project progresses.
ì This enables organiza>ons to change the project and deliverables at any point in >me, delivering the most appropriate release.
ì The SCRUM methodology frees developers to devise the most ingenious solu>ons throughout the project, as learning occurs and the environment changes.
ì Small, collabora>ve teams of developers are able to share tacit knowledge about development processes.
Advantages (2)
ì Object Oriented technology provides the basis for the SCRUM methodology.
ì Objects, or product features, offer a discrete and manageable environment.
ì Procedural code, with its many and intertwined interfaces, is inappropriate for the SCRUM methodology.
ì SCRUM may be selec>vely applied to procedural systems with clean interfaces and strong data orienta>on.
Some difficulties
Get set go!
References
ì Ken Schwaber. “SCRUM Development Process” <h[p://home.hib.no/ai/data/master/mod251/2009/ar>cles/scrum.pdf>
ì h[p://en.wikipedia.org/wiki/Scrum_(development)
ì h[p://www.crisp.se/henrik.kniberg/presenta>ons/Scrum-‐Intro-‐Brief-‐Henrik-‐Kniberg.pdf