Agile and Scrum Basics
7 likes2,917 views
The document explains common myths about Agile and Scrum practices, emphasizing that Agile is not equal to chaos or faster delivery, but rather focuses on delivering value and adapting to change. It covers key concepts such as user stories, themes, and epics within Scrum, outlining the roles and ceremonies essential for effective implementation. Additionally, it discusses the importance of company culture in embracing Agile principles beyond just software development.
Agile and Scrum Basics
- 1. Basics of Agile & Scrum Mazhar Khan
- 3. Agile Myth #1 Agile = No documentation “Working software over comprehensive documentation” is often misunderstood with no documentation at all. But how could agile Frameworks like Scrum survive in highly regulated environments like the medical or financial industry if this were to be true. For sure there is documentation, but we don’t waste time on documents that deliver no value to the project.
- 4. Agile Myth #2 Agile = Anarchy The biggest fear of any manager is to lose control over their agile teams. Self organization is often interpreted as anarchy. Management is required to define clear visions and goals and the constraints of a project
- 5. Agile Myth #3 Agile = Faster It isn't faster just because it’s called a Sprint! Writing quality software is serious business and takes time. One cannot guarantee that doing Agile would mean delivering faster. However one could guarantee having delivered much higher value in a comparable time.
- 6. Agile Myth #4 Agile = Silver Bullet Agile is not the only solution know to mankind! However strong the case of merits and values can be put forth, one can’t deny that several successful products have been delivered using waterfall or other methodologies. Its not a one size fits all approach . It’s all about people after all…
- 7. Agile Myth #5 Agile = Simple Switch It’s more got to do with “being” Agile and not “doing” Agile. While a simple 2-day course might arm you with the basic concepts it might take long to imbibe the principles that Agile methods are based on
- 8. Agile Myth #6 Agile = Easy To be able to deliver a potentially shippable product every 2-4 weeks is not easy. Not many development methodologies can even attempt this. Considering Agile to be easy would be detrimental. However, once the team is Agile-mature, it does run like a well oiled engine with minimum interference.
- 9. Agile Myth #7 Agile = Software Development Often the agile journey starts with software development, but it should not stop there. To have an agile software development team in an non- agile environment is like planting a tree in the desert - it won’t survive. The whole company culture has to change, everybody needs to adhere to the agile principles like lean thinking.
- 10. Agility overcomes… Communication Problems The delivered solution isn’t really what the business wanted Unused Features Building the right thing – the business changing their mind Delayed or late Return on Investment (ROI) Over-engineering (‘Gold plating’)
- 11. SCRUM Basics
- 12. Scrum Roles
- 13. Scrum Shot!
- 15. Scrum Requirements User Story - A story is a self-contained unit of work agreed upon by the developers and the stakeholders. Stories are the heart of Scrum, and the building blocks of your sprint. E.g. As a salesperson, I'd like to set my password, so I can log into the system Theme – A group of related stories contributing to a common goal or are related in some obvious way, such as all focusing on a single customer. However, while some stories in a theme may be dependent on one another, they do not need to encapsulate a specific work flow or be delivered together Epic - Epics resemble themes in the sense that they are made up of multiple stories. They may also resemble stories in the sense that, at first, many appear to simply be a "big story." As opposed to themes, however, these stories often comprise a complete work flow for a user and their business value isn't realized until the entire epic is complete
- 16. Scrum Artifacts
- 17. Scrum Artifacts Product Backlog - Prioritized features list, containing short descriptions of all functionality desired in the product typically written by the Product Owner and the Scrum Team Sprint Backlog – List of user stories identified during a Sprint Planning meeting by the Scrum team to be completed in a Sprint Potentially Shippable Product - A potentially shippable product is one that is ready for distribution to anyone in the company for review or even to any external stakeholder. Adhering to a list of “done” criteria ensures that the sprint product is truly shippable
- 18. Scrum Ceremonies
- 19. Sprint Planning Meeting WHEN – At the start of each Sprint, usually day long WHO – Product Owner, Scrum Master and the entire Scrum team. Outside stakeholders may attend by invitation of the team WHAT Product Owner - Describes the highest priority features to the team Team – Ask questions, refine the user stories, commit to a set of user stories that would be delivered in the sprint and do task break down Scrum Master – Facilitates, servant-leader Outcome Sprint goal Sprint Backlog
- 21. Daily Standup meeting WHEN – Each day of the Sprint at a fixed place at a fixed time (time-boxed to 15 minutes) WHO – Product Owner, Scrum Master and the entire Scrum team WHAT – Each participant answers the following questions What did I do yesterday? What will I do today? Are there any impediments in my way? Outcome Update the story board / progress Team members make commitments to each other Impediments list modified
- 22. Sprint Review / Demo
- 23. Sprint Review / Demo WHEN – At the end of each Sprint (Four-hour time limit) WHO – Product Owner, Scrum Master, the entire Scrum team, management and stakeholders WHAT – Demonstrate working software No PowerPoint presentations Presented as a natural result of the sprint vis-à-vis the set Sprint Goal Outcome Record feedback
- 25. Sprint Retrospective WHEN – At the end of each Sprint (Three-hour time limit) WHO – Product Owner, Scrum Master, the entire Scrum team WHAT – Reflect on the Sprint metrics Discuss what went good Discuss what needs to be improved Discuss continuous improvements Outcome Record feedback and create actionable items for improvements
- 26. Metrics – Sprint Burn down Graphical representation of work left to do versus time
- 27. Metrics – Velocity Trend Velocity is how much product backlog effort a team can handle in one sprint
- 28. References & Vote of Thanks! Marc Löffler - 7 Agile Myths DSDM Handbook Jeremy Jarrell - Stories versus Themes versus Epics Wikipedia – Scrum (software development) Scrum Alliance ! - None of the images have been created and have been simply used after an preliminary assessment of their copyright. Kindly contact the author in case of any discrepancy and the image will be removed
- 29. Be Agile, not just Do Agile Thank you!