Scrum introduction
Download as PPTX, PDF0 likes1,005 views
Scrum is an agile framework for managing software development projects that focuses on iterative delivery through short cycles called sprints. It utilizes roles like the product owner, development team, and scrum master. Key artifacts include the product backlog to track features and the sprint backlog to plan work for each iteration. Regular meetings like daily stand-ups, sprint reviews, and retrospectives promote transparency and process improvement. While long-term estimates are challenging, scrum values transparency and frequent delivery to build trust with stakeholders.
More Related Content
Scrum introduction
- 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 ...