An attempt to explain SCRUM to team with no knowledge about SCRUM.

1. SCRUM
... something like quick explanation
… but boring :-) ...

2. Why SCRUM (Agile) ?
• Nobody is perfect
• We are not able to estimate long periods of time
• (Be honest ...)
• ... proven and widely used framework/method

3. Nobody is perfect
• There is no person what can do everything
• There is no person what can make decisions about everything
• So we need ... „team inteligence“

4. We are not able to estimate long periods of
time
• Try that 
• Of course there are scientific studies
• So what ?
• We should accept world with just short accurate estimations
• But nobody is perfect... Team intelligence ...
• Similar to engine power value, but uncertain about time frame
• We should also inform customers – be honest
• We can still have a big plans about what should be done
• But we, all, should be prepared to change them

5. Be honest
• ...
• Do not lie
• to customer
• to management
• to yourself
• Honestly show the status
• Then you will be trustable
• Fail quickly
• It is cheap !
• Needed for Check, Analyze, Improve

6. AGILE
• Just a way of thinking – mindset
• Plan
• Act
• Analyze
• Improve
• … Repeat ! :-)

7. SCRUM
• Agile method
• See Agile Manifesto
• Well known
• Suitable for „classic“ software development
• It means traditional releases
• Scrum.org
• Scrumalliance.org
• SCRUM on Wikipedia

8. Roles
• Product owner
• Responsible for what should be done
• Features, bugs, tests
• „Managing“ stakeholders and their requirements
• Developer
• A team of developers (3-9), testers, analytics … whatever is needed
• Responsible for work to be done
• Responsible for technical decisions
• SCRUM master
• Responsible for the following of the SCRUM
• Solving impediments

9. Artifacts – DB schema 
• Product backlog
• What should be done
• Priority
• Product owner
• Sprint backlog
• Commitment of dev team - what will be done during sprint
• Impediments
• What is blocking development
• SCRUM master

10. Meetings
• Planning
• Daily SCRUM
• Review
• Retrospective

11. Meetings: Planning
• Usually divided to backlog grooming an sprint planning
• Backlog grooming
• Estimation of PBIs by dev team
• If not able to estimated Then PO should improve description or
divide PBI
• Sprint planning
• Team will decide /commit whose items will be delivered in sprint
• Can be divided to two meetings. Sprint planning and backlog
grooming
• 2 hours per week max (together)

12. Meetings: Daily SCRUM
• All dev will answer three question:
• What was done
• I'm working on
• Do You need help ?
• .. . also there can be Impediment – I can't work because ...
• 15 min max
• Every workday. The same place. The same time.

13. Meetings: Review
• Presentation what was done by dev team
• A real presentation. Real software-product.
• PO, stakeholders
• Are they satisfied ?
• Any comments ?
• … presentations ..
• This is the place for interaction dev team – PO,stakeholders
• 2 hours per week max

14. Meetings: Retrospective
• What was good
• What was bad
• What is needed (what can be improved)
• Most important meeting. There are books about that.
• 2 hours per week max

15. Artifacts: Product backlog - Organization
• Can be changed anytime by PO
• Priority
• Description
• Test case
• Anybody can add (usually)
• Bugs, refactoring pbis, etc ...
• Just PO can approve
• Visible for stakeholders
• They can see prority, forecast

16. Sprint organization
• 1-4 weeks
• Sprint backlog can be changed just during sprint planning meeting
• No stakeholder can discuss tasks during the sprint with dev team.
• PO should be able to answer questions about PBIs
• Tasks are not assigned but "taken" by developers
• Meaning of "Done" is defined by team
• PO should define simple goal of sprint
• If something wrong happen dev team can prioritize his effort
• Sprint backlog can be visible for stakeholders as well

17. So...
• SCRUM is proven framework for SW development
• Used worldwide
• There are trainings, certificates, books, videos …
• Even if there is no long term planning it is trustworthy because
everything is visible for stakeholders
• And it is simple :-)
• .. and supported by many many tools ...