Scrum is an agile framework for managing software development projects, characterized by short development cycles called sprints, daily stand-up meetings, and emphasis on self-organizing cross-functional teams. Key roles include the product owner, who prioritizes features; the scrum master, who facilitates the process; and the development team. Scrum uses artifacts like the product backlog, sprint backlog, and burndown charts to track progress. Ceremonies like sprint planning, daily scrums, sprint reviews, and retrospectives promote inspection and adaptation.
Introduction to agile and Scrum.
Using Vera Peeters and Pascal Van Cauwenberghe's XP game as a basis, we have adapted it to explain and demonstrate agile and Scrum. The second half of the presentation is largely repetitive because it is used at each stage in the game.
Training materials for Agile Scrum. Starts with an overview of Agile and Lean. Followed with the Agile Scrum key concepts like Product Owner, Scrum Master, Scrum Team and Product Backlog. Theory is complemented with learnings and best practices from real life software development.
This talk is a 101-level introduction to Scrum, the agile methodology, especially in terms of how it works for web development. We'll cover the scrum values, rituals, and team. We'll also discuss some common pitfalls and how to work around them.
Scrum is an iterative and incremental agile software development methodology for managing product development. It defines "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as illustrated by Teradata Consultant Prasanna Yaddanapudi in Feb Session
the presentation gives brief description about a methodology of software engineering which is most using software engineering process in today's IT world and helps student to know how a software company runs and build software product using various software engineering methodologies.
Planeación de proyectos ágil con Planning PokerSoftware Guru
El objetivo de este webinar es comprender cómo participar en una reunión de planeación ágil de proyectos de software utilizando el marco de trabajo Planning Poker.
En el webinar se transmitirán conceptos teóricos como los roles en Scrum de las reuniones de planeamiento, reuniones diarias y como experiencias prácticas durante las cuales quienes concurran podrán aprender a planificar y estimar utilizando un plugin llamado Planning Poker for Hangouts.
Al finalizar el webinar podrás estimar proyectos ágiles basándote en los individuos y la herramienta de Planning Poker.
This presentation describes the basics of Agile methodologies and how it is differed from Waterfall. Then continues with the most famous Agile approach: Scrum
Introduction to agile and Scrum.
Using Vera Peeters and Pascal Van Cauwenberghe's XP game as a basis, we have adapted it to explain and demonstrate agile and Scrum. The second half of the presentation is largely repetitive because it is used at each stage in the game.
Training materials for Agile Scrum. Starts with an overview of Agile and Lean. Followed with the Agile Scrum key concepts like Product Owner, Scrum Master, Scrum Team and Product Backlog. Theory is complemented with learnings and best practices from real life software development.
This talk is a 101-level introduction to Scrum, the agile methodology, especially in terms of how it works for web development. We'll cover the scrum values, rituals, and team. We'll also discuss some common pitfalls and how to work around them.
Scrum is an iterative and incremental agile software development methodology for managing product development. It defines "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal" as illustrated by Teradata Consultant Prasanna Yaddanapudi in Feb Session
the presentation gives brief description about a methodology of software engineering which is most using software engineering process in today's IT world and helps student to know how a software company runs and build software product using various software engineering methodologies.
Planeación de proyectos ágil con Planning PokerSoftware Guru
El objetivo de este webinar es comprender cómo participar en una reunión de planeación ágil de proyectos de software utilizando el marco de trabajo Planning Poker.
En el webinar se transmitirán conceptos teóricos como los roles en Scrum de las reuniones de planeamiento, reuniones diarias y como experiencias prácticas durante las cuales quienes concurran podrán aprender a planificar y estimar utilizando un plugin llamado Planning Poker for Hangouts.
Al finalizar el webinar podrás estimar proyectos ágiles basándote en los individuos y la herramienta de Planning Poker.
This presentation describes the basics of Agile methodologies and how it is differed from Waterfall. Then continues with the most famous Agile approach: Scrum
Scrum is the most popular Agile Framework; during this presentation the attendees will understand the value, and an overview of the powerful scrum framework: its roles, its artifacts and its ceremonies
Detail Information about Agile Process Frameworks such as SCRUM and CMMI along with agile manifesto. Comparison between scrum and capability maturity model integration
Traditional software development models (such as Waterfall) are based upon a
defined methodology which attempts to define requirements up front, logically
break down the work estimate plan then begin development while trying to
SCRUM – How It Differs
work, estimate, plan, development, limit/control change which will threaten the plan. These are based upon Defined
Process Model theory which was adopted from manufacturing and applied to
software development.
Agile and Scrum 101 – basics of Agile and Scrum
Scrum in 100 words:
• Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time.
• It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).
• The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.
• Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.
In the presentation we discuss the basics of Agile and Scrum, the roles, ceremonies and artifacts. We add from our, from the trenches, lessons learned and better practices.
0x01 - Newton's Third Law: Static vs. Dynamic AbusersOWASP Beja
f you offer a service on the web, odds are that someone will abuse it. Be it an API, a SaaS, a PaaS, or even a static website, someone somewhere will try to figure out a way to use it to their own needs. In this talk we'll compare measures that are effective against static attackers and how to battle a dynamic attacker who adapts to your counter-measures.
About the Speaker
===============
Diogo Sousa, Engineering Manager @ Canonical
An opinionated individual with an interest in cryptography and its intersection with secure software development.
This presentation by Morris Kleiner (University of Minnesota), was made during the discussion “Competition and Regulation in Professions and Occupations” held at the Working Party No. 2 on Competition and Regulation on 10 June 2024. More papers and presentations on the topic can be found out at oe.cd/crps.
This presentation was uploaded with the author’s consent.
Sharpen existing tools or get a new toolbox? Contemporary cluster initiatives...Orkestra
UIIN Conference, Madrid, 27-29 May 2024
James Wilson, Orkestra and Deusto Business School
Emily Wise, Lund University
Madeline Smith, The Glasgow School of Art
Acorn Recovery: Restore IT infra within minutesIP ServerOne
Introducing Acorn Recovery as a Service, a simple, fast, and secure managed disaster recovery (DRaaS) by IP ServerOne. A DR solution that helps restore your IT infra within minutes.
Have you ever wondered how search works while visiting an e-commerce site, internal website, or searching through other types of online resources? Look no further than this informative session on the ways that taxonomies help end-users navigate the internet! Hear from taxonomists and other information professionals who have first-hand experience creating and working with taxonomies that aid in navigation, search, and discovery across a range of disciplines.
This presentation, created by Syed Faiz ul Hassan, explores the profound influence of media on public perception and behavior. It delves into the evolution of media from oral traditions to modern digital and social media platforms. Key topics include the role of media in information propagation, socialization, crisis awareness, globalization, and education. The presentation also examines media influence through agenda setting, propaganda, and manipulative techniques used by advertisers and marketers. Furthermore, it highlights the impact of surveillance enabled by media technologies on personal behavior and preferences. Through this comprehensive overview, the presentation aims to shed light on how media shapes collective consciousness and public opinion.
4. Empirical Process
• Visibility: those aspects of the process that affect the
outcome must be visible to those controlling the process.
• Inspection: those aspects of the process that affect the
outcome must be inspected frequently enough that
unacceptable variances in the process can be detected.
• Adaptation: If the inspector determines from the inspection
that one or more aspects of the process are outside
acceptable limits and that the resulting product will be
unacceptable, the inspector must adjust the process or the
material being processed.
5. Visibility
What is the actual (not ideal) relationship between these aspects
and the outcome?
• Design Artefacts
• Spike Solutions
• Test Frameworks
• Automated Tests
• Design patterns and coding standards
• Product Increments
6. Inspection
• What is the actual (not ideal) relationship between these aspects and
the outcome?
• Design Artefacts
• Spike Solutions
• Test Frameworks
• Automated Tests
• Design patterns and coding standards
• Product Increments
• How do you inspect these aspects?
7. Adaptation
• Adjust the process or the material being processed
• Making decisions based on information that was not known at the
outset of the project
• Refusing to decide is a decision: the team accepts accountability for
averting disaster by managing priorities
8. Scrum is Defined
• Is an agile, lightweight process
• Can manage and control software and product development
• Uses iterative, incremental practices
• Has a simple implementation
• Increases productivity
• Reduces time to benefits
• Embraces adaptive, empirical systems development
• Is not restricted to software development projects
9. Scrum has a mindset
• Scrum is commitment-oriented: You’ll be introduced to chickens
later.
• Scrum is results-oriented: projects produce increments of a
shippable product, activities are time boxed, and ceremony is
discouraged.
• Scrum is disciplined. There are practices you must follow on a
specified time table.
10. Characteristics
• Self-organizing teams
• Product progresses in a series of month-long “sprints”
• Requirements are captured as items in a list of “product
backlog”
• No specific engineering practices prescribed
• Uses generative rules to create an agile environment for
delivering projects
• One of the “agile processes”
11. Scrum origins
• Jeff Sutherland
• Initial scrums at Easel Corp in 1993
• IDX and 500+ people doing Scrum
• Ken Schwaber
• ADM
• Scrum presented at OOPSLA 95 with Sutherland
• Author of three books on Scrum
• Mike Beedle
• Scrum patterns in PLOPD4
• Ken Schwaber and Mike Cohn
• Co-founded Scrum Alliance in 2002, initially
within the Agile Alliance
12. Scrum has been used by:
•Microsoft
•Yahoo
•Google
•Electronic Arts
•High Moon Studios
•Lockheed Martin
•Philips
•Siemens
•Nokia
•Capital One
•BBC
•Intuit
•Intuit
•Nielsen Media
•First American Real Estate
•BMC Software
•Ipswitch
•John Deere
•Lexis Nexis
•Sabre
•Salesforce.com
•Time Warner
•Turner Broadcasting
•Oce
13. Agile Manifesto
Process and tools
Individuals and
interactions
over
Following a plan
Responding to
change
over
Comprehensive
documentation
Working software over
Contract negotiation
Customer
collaboration
over
17. Scrum Roles
• Product Owner
• Possibly a Product Manager or Project Sponsor
• Decides features, release date, prioritization, $$$
• Scrum Master
• Typically a Project Manager or Team Leader
• Responsible for enacting Scrum values and practices
• Remove impediments / politics, keeps everyone productive
• Project Team
• 5-10 members; Teams are self-organizing
• Cross-functional: QA, Programmers, UI Designers, etc.
• Membership should change only between sprints
18. Product owner
• Define the features of the product
• Decide on release date and content
• Be responsible for the profitability of the product (ROI)
• Prioritize features according to market value
• Adjust features and priority every iteration, as needed
• Accept or reject work results
19. The Scrum Master
• Represents management to the project
• Responsible for enacting Scrum values and practices
• Removes impediments
• Ensure that the team is fully functional and productive
• Enable close cooperation across all roles and functions
• Shield the team from external interferences
20. The team
• Typically 5-9 people
• Cross-functional:
• Programmers, testers, user experience designers, etc.
• Members should be full-time
• May be exceptions (e.g. database administrator)
21. The team
• Teams are self-organizing
• Ideally, no titles but rarely a possibility
• Membership should change only between sprints
24. Sprints
• Scrum projects make progress in a series of “sprints”
• Analogous to Extreme Programming iterations
• Typical duration is 2–4 weeks or a calendar month at most
• A constant duration leads to a better rhythm
• Product is designed, coded, and tested during the sprint
25. The Sprint Planning Meeting
• Product Owner describes highest priority features to the Team.
• Team decides what the can commit to delivering in the Sprint.
• For a one month or four-week sprint this meeting should last eight
hours.
• For a two-week sprint, plan for about four hours.
• General rule of thumb, multiply the number of weeks in your sprint
by two hours to get your total sprint planning meeting length.
• The Sprint Planning Meeting is typically broken into two parts.
26. Part One: Four Hours (One Month Sprint)
• The Product Owner selects the ideal backlog for the coming Sprint
and communicates its meaning and importance to the team.
• Chickens may be invited to provide clarification, but they are
immediately dismissed.
• Team may ask questions.
27. Part Two: Four Hours (One Month Sprint)
• The Team decides how much it can commit to delivering in the
coming Sprint.
• The Product Owner answers questions but does not direct the team’s
choices. No chickens allowed.
• The outcome is the Sprint Backlog.
28. Daily Scrum Meeting
• Parameters
• Daily, ~15 minutes, Stand-up
• Everyday at constant time
• Not for problem solving
• Whole world is invited
• Only team members, Scrum Master, product owner, can talk
• Helps avoid other unnecessary meetings
• Three questions answered by each team member:
1. What did you do yesterday?
2. What will you do today?
3. What obstacles are in your way?
29. The sprint review
• Team presents what it accomplished during the sprint
• Typically takes the form of a demo of new features or underlying
architecture
• Informal
• One hour for one week sprint.
• No slides
• Whole team participates
• Invite the world
30. Sprint retrospective
• Periodically take a look at what is and is not working
• 45 minutes for each week of Sprint duration.
• Done after every sprint
• Whole team participates
• Scrum Master
• Product owner
• Team
• Possibly customers and others
31. Everyone answers 3 questions
• These are not status for the ScrumMaster
• They are commitments in front of peers
What did you do yesterday?
1
What will you do today?
2
Is anything in your way?
3
33. Scrum's Artifacts
• Scrum has remarkably few artifacts
• Product Backlog
• Sprint Backlog
• Burndown Charts
• Can be managed using just an Excel spreadsheet
• More advanced / complicated tools exist:
• Expensive
• Web-based – no good for Scrum Master/project manager who travels
• Still under development
34. Product Backlog
• The requirements
• A list of all desired work on
project
• Ideally expressed as a list of user
stories along with "story points",
such that each item has value to
users or customers of the product
• Prioritized by the product owner
• Reprioritized at start of each
sprint
This is the
product backlog
35. Sample Product Backlog
Backlog item Estimate
Allow a guest to make a reservation 3 (story points)
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a reservation. 3
As a hotel employee, I can run RevPAR reports (revenue-
per-available-room)
8
Improve exception handling 8
... 30
... 50
36. User Stories
• Instead of Use Cases, Agile project owners do "user stories"
• Who (user role) – Is this a customer, employee, admin, etc.?
• What (goal) – What functionality must be achieved/developed?
• Why (reason) – Why does user want to accomplish this goal?
As a [user role], I want to [goal], so I can [reason].
• Example:
• "As a user, I want to log in, so I can access subscriber content."
• story points: Rating of effort needed to implement this story
• common scales: 1-10, shirt sizes (XS, S, M, L, XL), etc.
38. Estimation – Playing Poker
• Each team member is given a set of cards with numbers on them.
• The numbers are usually ordered from 0 to 21 using the Fibonacci
sequence: 0, 1, 2, 3, 5, 8, 13, and 21.
• Then each story is read aloud by PO.
• After each story is presented, everybody on the team is asked to hold
up the card showing the level of effort that they believe this story
represents for the team.
• Once all the votes are in, the team members with the lowest and
highest estimates explain why they chose their scores.
• Once all the votes are in, the team members with the lowest and
highest estimates explain why they chose their scores.
• Stories estimated at 20 or higher may be so large that they need to
broken up into smaller stories before they can be attempted.
39. Sprint Backlog
• Individuals sign up for work of their own choosing
• Work is never assigned
• Estimated work remaining is updated daily
• Any team member can add, delete change sprint backlog
• Work for the sprint emerges
• If work is unclear, define a sprint backlog item with a larger amount
of time and break it down later
• Update work remaining as more becomes known
40. Sample Sprint backlog
Tasks
Code the user interface
Code the middle tier
Test the middle tier
Write online help
Write the Foo class
Mon
8
16
8
12
8
Tue
4
12
16
8
Wed Thu
4
11
8
4
Fri
8
8
Add error logging
8
10
16
8
8
41. Sprint Burndown Chart
• A display of what work has been completed
and what is left to complete
• one for each developer or work item
• updated every day
• (make best guess about hours/points completed each day)
• variation: Release burndown chart
• shows overall progress
• updated at end of each sprint
45. The Product Increment
• Delivers measurable value
• “Potentially Shippable”: the process can be halted after every Sprint
and there will be some value, some ROI
• Must be a product, no matter how incomplete
46. Scalability
• Typical individual team is 7 ± 2 people
• Scalability comes from teams of teams
• Factors in scaling
• Type of application
• Team size
• Team dispersion
• Project duration
• Scrum has been used on multiple 500+ person projects
49. Credits, References
• Mike Cohn, Mountain Goat Software
www.mountaingoatsoftware.com
• Scrum and The Enterprise by Ken Schwaber
• Succeeding with Agile by Mike Cohn
• Agile Software Development Ecosystems by Jim Highsmith
• Agile Software Development with Scrum by K. Schwaber and M.
Beedle
• User Stories Applied for Agile Software Development by Mike Cohn
• www.agilescrum.com/
• www.objectmentor.com
• jeffsutherland.com/
• www.controlchaos.com/scrumwp.htm
• agilealliance.com/articles/articles/InventingScrum.pdf