The document provides an overview of Agile methodology and SCRUM framework. It discusses key aspects of SCRUM such as product backlog, sprint backlog, daily stand-ups, and burndown charts. It also covers Agile concepts like cross-functional teams, iterative development, and responding to change. The document aims to introduce readers to the basic principles and practices of Agile software development using SCRUM.
25. Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
26. Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
27. Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
28. Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
29. Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
30. Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
31. Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick
65. Customer Feedback
Just one
more thing...
This is wrong!
Cool Stuff!
Found a bug!
66. Customer Feedback
Just one
more thing...
This is wrong!
Cool Stuff!
Found a bug!
While you’re
at it...
67. Customer Feedback
Just one Is it more important than
more thing... the next feature?
This is wrong!
Cool Stuff!
Found a bug!
While you’re
at it...
68. Customer Feedback
Just one Is it more important than
more thing... the next feature?
This is wrong!
Cool Stuff! Oops... we’ll fix it!
Found a bug!
While you’re
at it...
69. Customer Feedback
Just one Is it more important than
more thing... the next feature?
This is wrong!
Cool Stuff! Oops... we’ll fix it!
Found a bug!
While you’re
at it... Next version...
83. Courage!
• Quality work
• Make things simple
From Agile in a Flash
84. Courage!
• Quality work
• Make things simple
• Go for the hard problem
From Agile in a Flash
85. Courage!
• Quality work
• Make things simple
• Go for the hard problem
• Architectural corrections
From Agile in a Flash
86. Courage!
• Quality work
• Make things simple
• Go for the hard problem
• Architectural corrections
• Throw away
From Agile in a Flash
87. Courage!
• Quality work
• Make things simple
• Go for the hard problem
• Architectural corrections
• Throw away
• Only complete work
From Agile in a Flash
88. Courage!
• Quality work
• Make things simple
• Go for the hard problem
• Architectural corrections
• Throw away
• Only complete work
• Be transparent
From Agile in a Flash
193. Agile Success Factors
• Freedom to change
• Energized team
• Communication with customer
From Agile in a Flash
194. Agile Success Factors
• Freedom to change
• Energized team
• Communication with customer
• Collaboration
From Agile in a Flash
195. Agile Success Factors
• Freedom to change
• Energized team
• Communication with customer
• Collaboration
• Attention to quality
From Agile in a Flash
196. Agile Success Factors
• Freedom to change
• Energized team
• Communication with customer
• Collaboration
• Attention to quality
• Incrementalism
From Agile in a Flash
197. Agile Success Factors
• Freedom to change
• Energized team
• Communication with customer
• Collaboration
• Attention to quality
• Incrementalism
• Automation
From Agile in a Flash
Balancing Agility and Discipline: A Guide for the Perplexed\n
Balancing Agility and Discipline: A Guide for the Perplexed\n
Balancing Agility and Discipline: A Guide for the Perplexed\n
Balancing Agility and Discipline: A Guide for the Perplexed\n
Balancing Agility and Discipline: A Guide for the Perplexed\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Vision: A general idea for the app (as opposed to a rigid set of requirements)\nProduct Backlog: A list of requirements, sorted by priority\nIteration Backlog: The top most item of the backlog, that fits in an iteration\nIteration: Were dev magic occurs. Typically lasts 2 weeks.\nCustomer participation is paramount!\nPSP: Potentially shippable product\nBack to product backlog, that can change, with the participation of the customer.\n
Vision: A general idea for the app (as opposed to a rigid set of requirements)\nProduct Backlog: A list of requirements, sorted by priority\nIteration Backlog: The top most item of the backlog, that fits in an iteration\nIteration: Were dev magic occurs. Typically lasts 2 weeks.\nCustomer participation is paramount!\nPSP: Potentially shippable product\nBack to product backlog, that can change, with the participation of the customer.\n
Vision: A general idea for the app (as opposed to a rigid set of requirements)\nProduct Backlog: A list of requirements, sorted by priority\nIteration Backlog: The top most item of the backlog, that fits in an iteration\nIteration: Were dev magic occurs. Typically lasts 2 weeks.\nCustomer participation is paramount!\nPSP: Potentially shippable product\nBack to product backlog, that can change, with the participation of the customer.\n
Vision: A general idea for the app (as opposed to a rigid set of requirements)\nProduct Backlog: A list of requirements, sorted by priority\nIteration Backlog: The top most item of the backlog, that fits in an iteration\nIteration: Were dev magic occurs. Typically lasts 2 weeks.\nCustomer participation is paramount!\nPSP: Potentially shippable product\nBack to product backlog, that can change, with the participation of the customer.\n
Vision: A general idea for the app (as opposed to a rigid set of requirements)\nProduct Backlog: A list of requirements, sorted by priority\nIteration Backlog: The top most item of the backlog, that fits in an iteration\nIteration: Were dev magic occurs. Typically lasts 2 weeks.\nCustomer participation is paramount!\nPSP: Potentially shippable product\nBack to product backlog, that can change, with the participation of the customer.\n
Vision: A general idea for the app (as opposed to a rigid set of requirements)\nProduct Backlog: A list of requirements, sorted by priority\nIteration Backlog: The top most item of the backlog, that fits in an iteration\nIteration: Were dev magic occurs. Typically lasts 2 weeks.\nCustomer participation is paramount!\nPSP: Potentially shippable product\nBack to product backlog, that can change, with the participation of the customer.\n
Vision: A general idea for the app (as opposed to a rigid set of requirements)\nProduct Backlog: A list of requirements, sorted by priority\nIteration Backlog: The top most item of the backlog, that fits in an iteration\nIteration: Were dev magic occurs. Typically lasts 2 weeks.\nCustomer participation is paramount!\nPSP: Potentially shippable product\nBack to product backlog, that can change, with the participation of the customer.\n
Vision: A general idea for the app (as opposed to a rigid set of requirements)\nProduct Backlog: A list of requirements, sorted by priority\nIteration Backlog: The top most item of the backlog, that fits in an iteration\nIteration: Were dev magic occurs. Typically lasts 2 weeks.\nCustomer participation is paramount!\nPSP: Potentially shippable product\nBack to product backlog, that can change, with the participation of the customer.\n
Vision: A general idea for the app (as opposed to a rigid set of requirements)\nProduct Backlog: A list of requirements, sorted by priority\nIteration Backlog: The top most item of the backlog, that fits in an iteration\nIteration: Were dev magic occurs. Typically lasts 2 weeks.\nCustomer participation is paramount!\nPSP: Potentially shippable product\nBack to product backlog, that can change, with the participation of the customer.\n
Vision: A general idea for the app (as opposed to a rigid set of requirements)\nProduct Backlog: A list of requirements, sorted by priority\nIteration Backlog: The top most item of the backlog, that fits in an iteration\nIteration: Were dev magic occurs. Typically lasts 2 weeks.\nCustomer participation is paramount!\nPSP: Potentially shippable product\nBack to product backlog, that can change, with the participation of the customer.\n
Vision: A general idea for the app (as opposed to a rigid set of requirements)\nProduct Backlog: A list of requirements, sorted by priority\nIteration Backlog: The top most item of the backlog, that fits in an iteration\nIteration: Were dev magic occurs. Typically lasts 2 weeks.\nCustomer participation is paramount!\nPSP: Potentially shippable product\nBack to product backlog, that can change, with the participation of the customer.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Things that can impact the speed:\n- Team\n- Type of project (UI, code only, ...)\n\n
Things that can impact the speed:\n- Team\n- Type of project (UI, code only, ...)\n\n
Things that can impact the speed:\n- Team\n- Type of project (UI, code only, ...)\n\n
Things that can impact the speed:\n- Team\n- Type of project (UI, code only, ...)\n\n
Things that can impact the speed:\n- Team\n- Type of project (UI, code only, ...)\n\n
Things that can impact the speed:\n- Team\n- Type of project (UI, code only, ...)\n\n
Things that can impact the speed:\n- Team\n- Type of project (UI, code only, ...)\n\n
\n
\n
\n
\n
\n
\n
\n
- 60/60 rule\n- Book is from 2002. This is bigger with Agile.\n- There are some challenges here: Getting things into production; Getting user feedback; Technical debt; Upgrading processes\n- But let’s focus on bug fixing\n
- 60/60 rule\n- Book is from 2002. This is bigger with Agile.\n- There are some challenges here: Getting things into production; Getting user feedback; Technical debt; Upgrading processes\n- But let’s focus on bug fixing\n
- 60/60 rule\n- Book is from 2002. This is bigger with Agile.\n- There are some challenges here: Getting things into production; Getting user feedback; Technical debt; Upgrading processes\n- But let’s focus on bug fixing\n
- 60/60 rule\n- Book is from 2002. This is bigger with Agile.\n- There are some challenges here: Getting things into production; Getting user feedback; Technical debt; Upgrading processes\n- But let’s focus on bug fixing\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
- Team must be able to change its processes\n- Team must be eager do deliver value\n- Team must have a frequent and honest communication with customer\n- Collaboration within and beyond the team. Meetings != Collaboration\n- Never give up on quality\n- Small steps to everything\n- Automate the repetitive, error-prone time consuming tasks\n
- Team must be able to change its processes\n- Team must be eager do deliver value\n- Team must have a frequent and honest communication with customer\n- Collaboration within and beyond the team. Meetings != Collaboration\n- Never give up on quality\n- Small steps to everything\n- Automate the repetitive, error-prone time consuming tasks\n
- Team must be able to change its processes\n- Team must be eager do deliver value\n- Team must have a frequent and honest communication with customer\n- Collaboration within and beyond the team. Meetings != Collaboration\n- Never give up on quality\n- Small steps to everything\n- Automate the repetitive, error-prone time consuming tasks\n
- Team must be able to change its processes\n- Team must be eager do deliver value\n- Team must have a frequent and honest communication with customer\n- Collaboration within and beyond the team. Meetings != Collaboration\n- Never give up on quality\n- Small steps to everything\n- Automate the repetitive, error-prone time consuming tasks\n
- Team must be able to change its processes\n- Team must be eager do deliver value\n- Team must have a frequent and honest communication with customer\n- Collaboration within and beyond the team. Meetings != Collaboration\n- Never give up on quality\n- Small steps to everything\n- Automate the repetitive, error-prone time consuming tasks\n
- Team must be able to change its processes\n- Team must be eager do deliver value\n- Team must have a frequent and honest communication with customer\n- Collaboration within and beyond the team. Meetings != Collaboration\n- Never give up on quality\n- Small steps to everything\n- Automate the repetitive, error-prone time consuming tasks\n
- Team must be able to change its processes\n- Team must be eager do deliver value\n- Team must have a frequent and honest communication with customer\n- Collaboration within and beyond the team. Meetings != Collaboration\n- Never give up on quality\n- Small steps to everything\n- Automate the repetitive, error-prone time consuming tasks\n
- Much of it depends on you!\n- On your commitment\n- On your efforts to learn more\n- On your pledge to improve the quality of your work\n- On your courage\n- Agile only works with great teams. Great teams only work with great people. That means you!\n