Introduction to Scrum
•Download as PPTX, PDF•
0 likes•92 views
Scrum is an agile framework for managing product development that focuses on iterative delivery of value through collaboration between self-organizing cross-functional teams. It emphasizes customer satisfaction, welcomes changing requirements, and delivers working software frequently in short development cycles called sprints, with daily stand-up meetings and sprint reviews and retrospectives at the end of each sprint.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Introduction to Scrum
Similar to Introduction to Scrum (20)
Recently uploaded
Recently uploaded (20)
Introduction to Scrum
- 1. Introduction to SCRUM Anil Kulkarni @agfieldmarshal agilefieldmarshal.com
- 3. Agile Principles Customer satisfaction through early and continuous delivery of valuable software Welcome changing requirements Deliver working software frequently Business people and developers must work together Build projects around motivated individuals and trust them to get the job done The most efficient and effective way of conveying information is face-to-face conversation Working software is a primary measure of progress Sustainable pace – indefinitely Continuous attention to technical excellence and good design enhances agility Simplicity – the art of maximizing the amount of work not done – is essential Self-organising teams At regular intervals, the team reflects on how to become more effective
- 4. Agile Methods • Scrum • Lean software development • Kanban • Extreme Programming - XP • Agile Unified Process – AUP • Crystal Clear • Disciplined Agile Delivery- DAD • Dynamic Systems development method – DSDM • Feature Driven Development – FDD • Adaptive Software Development
- 5. Scrum Tree
- 6. Scrum
- 11. Definition of Ready / Done
- 12. Sprint Planning
- 13. Sprint Execution
- 14. Sprint Execution
- 15. Sprint Review
- 16. Sprint Review
- 19. Sprints
Editor's Notes
- Empirical – Using data from the immediate past to predict the future outcome
- Vision – A product roadmap Each sprint is Timeboxed- 1 to 4 weeks : early progress and feedback, inspect and adapt, Helps in WIP, forces prioritisation , helps in predictability, Cadence – a regular rhythm (heartbeat)
- A prioritized collection of functionality that must be completed to make the product vision a reality PB Items: Epics, User Stories, Tasks. It can be use cases as well. No specific or prescribed format for how these PBIs are represented. Each PBI has a tangible value (for a user or customer) associated with it estimated (fine as well as coarse) Will contain MVP Product owner is the ultimate responsible person for maintaining this PB User Stories – a placeholder for conversation. 3 Cs – Card, Conversation and Confirmation. Conversation leads to having a shared understanding and is a richer form of exchanging information. Not all PBIs need to be specified in detail at the same time,
- Estimation based on Planning poker * Consensus based, expert opinion, open discussion, relative sizing, relatively accurate binning, historical
- PB is a living document, so it is evolved as the time progresses. It typically has four qualities D – detailed appropriately E – Estimated E - Emergent P – Prioritised
- Ready – The idea is not to have absolutely everything specified, but just enough for the team to have a shared understanding of the item to be completed during a sprint. INVEST – Independent, Negotiable, Valuable, Estimable, Small enough, Testable Negotiable – in terms of “how” the user story is implemented, determining scope of a story so it becomes viable to be delivered in the sprint.
- Product backlog with PBIs in “ready” state for the sprint
- Vertical slice of a product cake Important to work on the Sprint backlog items and not those outside of the Sprint backlog. Sprint backlog forms the commitment that the team made towards achieving the sprint goal.
- Daily Stand-up: Not a status meeting but a planning meeting between the team members. Collaboration is the key, stand up achieves synchronisation between team members. Its other purposes – create peer pressure, use fine gain coordination, making daily commitments and most importantly raising impediments Potentially shippable PI : delivery of “Working” software
- Demonstrate what was achieved during the sprint to internal and external stakeholders. It is also an opportunity to get an early feedback on the product and then adapt based on that feedback
- What did we learn from this sprint? Do we need to bring in any changes to work even more effectively?