Scrum Myths and Misconceptions
•
5 likes•663 views
Brisbane Agile Meetup on May 2017 - Mark Arrowsmith sharing his views on Scrum Myths and Misconceptions. He will dispel some of the most common Scrum myths and misconceptions and enlighten you on the realities of Scrum and some useful tips on how to be more successful with Scrum in your organisation from a scrum.org Professional Scrum Trainer. Mark Arrowsmith is an Agile Coach with Avanade and is based in the Brisbane/Gold Coast region in Australia. He is a Professional Scrum Trainer (PST) with Scrum.org and has extensive experience in executing projects using Scrum as well as 16+ years as a developer across a range of technologies but specializing in Microsoft .NET.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Scrum Myths and Misconceptions
Similar to Scrum Myths and Misconceptions (20)
Recently uploaded
Recently uploaded (20)
Scrum Myths and Misconceptions
- 1. ©2016 Avanade Inc. All Rights Reserved. Brisbane Agile Meetup – Scrum Myths and Misconceptions Mark Arrowsmith 18-May-2017
- 2. ©2016 Avanade Inc. All Rights Reserved. Scrum Myths and Misconceptions
- 3. ©2016 Avanade Inc. All Rights Reserved. Who am I? Agile Coach | Professional Scrum Trainer | Developer • Based in Brisbane, Australia • @Avanade since May 2011 • Passionate about Agile, Scrum & Continuous Improvement! • Random Stuff: Black Belt in Kung Fu, Robot Creator • LinkedIn: https://www.linkedin.com/in/markarrowsmith
- 4. ©2016 Avanade Inc. All Rights Reserved. What is Scrum? Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. • Scrum is: • One of the agile methods • Lightweight • Extremely simple to understand • Extremely difficult to master
- 5. ©2016 Avanade Inc. All Rights Reserved. The Scrum Framework
- 6. ©2016 Avanade Inc. All Rights Reserved. Myths – Scrum Events
- 7. ©2016 Avanade Inc. All Rights Reserved. MYTH: Scrum is meeting heavy REALITY: • Meetings in Scrum are time-boxed and each event has a specified purpose • Events in Scrum are opportunities for collaboration & feedback • [TIP] Try to minimize other non-Scrum meetings Myths – Scrum Events
- 8. ©2016 Avanade Inc. All Rights Reserved. MYTH: It is OK to have a Sprint 0, Design Sprint, Hardening Sprint… REALITY: • Every sprint should produce potentially releasable items of value • Architecture provides zero business value by itself, but it supports work that does • Testing including user testing should be done within the boundary of the sprint • [TIP] Even on Sprint 1, ensure at least one PBI get’s Done. Myths – Scrum Events
- 9. ©2016 Avanade Inc. All Rights Reserved. MYTH: The Daily Scrum is status meeting REALITY: • A short daily event to make a plan for the day’s work • It’s a meeting for the Development Team • Scrum Master is optional • [TIP] Mix up your Daily Scrum format – Try “walking the board” Myths – Scrum Events
- 10. ©2016 Avanade Inc. All Rights Reserved. MYTH: Everything must be planned out in the Sprint Planning meeting REALITY: • 2 parts to this meeting: • What can be done this Sprint? • How will the chosen work get done? • Software Development is complex • Emergent work is going to happen • [TIP] Reserve some capacity for emergent work Myths – Scrum Events
- 11. ©2016 Avanade Inc. All Rights Reserved. MYTH: The Sprint Review is a phase gate REALITY: • PBI could already be released to Production as part of Done (DoD) e.g.DevOps • Sprint Review is an opportunity to “inspect and adapt” the Increment and the Product Backlog (Feedback) • [TIP] Ask the Stakeholders for their opinions/feedback after reviewing each PBI Myths – Scrum Events
- 12. ©2016 Avanade Inc. All Rights Reserved. MYTH: The Sprint Review is the event to engage the Product Owner REALITY: • The Product Owner should be working with the Development Team and Scrum Master throughout the Sprint, not just at the beginning and end. • [TIP] Add Reviewed or Accepted by the Product Owner as part of the Definition of Done. • [TIP] Get the Product Owner to run the Sprint Review and drive getting feedback from the stakeholders Myths – Scrum Events
- 13. ©2016 Avanade Inc. All Rights Reserved. Myths – Scrum Roles
- 14. ©2016 Avanade Inc. All Rights Reserved. MYTH: The Scrum Master is a secretary for the team, taking down all the meeting notes and updating the board / burndown chart REALITY: The Scrum Master is a … Servant Leader, Facilitator, Coach, Conflict Navigator, Manager, Mentor, Teacher, Impediment Remover & Change Agent Myths – Scrum Roles
- 15. ©2016 Avanade Inc. All Rights Reserved. MYTH: The goal of the Scrum Master is make themselves unneeded REALITY: • The role of the Scrum Master will change depending on the team maturity and current situation Myths – Scrum Roles
- 16. ©2016 Avanade Inc. All Rights Reserved. MYTH: Everyone on the Development Team must be cross functional REALITY: • The Development Team must be cross functional and contain all the skills required to take PBI's and create a potentially shippable increment • The individual team members don’t need to be cross functional • Collective ownership & teamwork • [TIP] Pair up and work together often with other disciplines Myths – Scrum Roles
- 17. ©2016 Avanade Inc. All Rights Reserved. Myths – Scrum Artifacts
- 18. ©2016 Avanade Inc. All Rights Reserved. MYTH: Scrum requires User Stories REALITY: • User Stories are a complementary practice to Scrum but not part of Scrum itself. • Scrum calls items on the Product Backlog – PBIs • These PBIs can be: Bugs, Features, NFRs, Desirements etc. • Not everything fits neatly into the User Story format Myths – Scrum Artifacts
- 19. ©2016 Avanade Inc. All Rights Reserved. MYTH: Product Backlog can only be updated by the PO REALITY: • The PO is not a secretary • Anyone can add the Product Backlog • However the order of the Product Backlog should be decided by the PO • [Tip] Use a basic workflow on the status of an PBI Myths – Scrum Artifacts
- 20. ©2016 Avanade Inc. All Rights Reserved. MYTH: Sprint Backlog = Sprint Commitment REALITY: • The team forecasts the work! Scrum Guide: July 2013 • The team commits to the Sprint Goal, not the Sprint Backlog • The Sprint Backlog can change (see other myth) • Perfect Knowledge = When Done • Plan != Guarantee Myths – Scrum Artifacts
- 21. ©2016 Avanade Inc. All Rights Reserved. Myths – Scrum in General
- 22. ©2016 Avanade Inc. All Rights Reserved. MYTH: Increasing Velocity means increased team productivity REALITY: • Velocity is purely a metric for capacity planning • Velocity is neither good nor bad! • Velocity will vary even in mature Scrum teams • [TIP] Use Velocity during Sprint Planning but not as a productivity indicator Myths – Scrum in General
- 23. ©2016 Avanade Inc. All Rights Reserved. MYTH: Burn Down Charts are required by Scrum REALITY: • They used to be included in the Scrum guide but was removed in 2011. • Other tracking methods can be used • [TIP] If you get value out this practice – keep it if not – discard it and maybe try something else Myths – Scrum in General
- 24. ©2016 Avanade Inc. All Rights Reserved. MYTH: Scrum requires Story Point estimation REALITY: • Not in the Scrum guide • Story Point estimation is a complementary practice • It’s a common Agile estimation technique • [TIP] Give other estimation techniques a try Myths – Scrum in General
- 25. ©2016 Avanade Inc. All Rights Reserved. MYTH: Scrum should be modified to fit the organisation REALITY: • Scrum is a lightweight framework • Every Scrum artifact, role, & event (including time-boxes) are designed to provide benefits and address predictable recurring problems • [TIP] Add complementary practices but ensure they add value Myths – Scrum in General
- 26. ©2016 Avanade Inc. All Rights Reserved. Call to Action 1. Re-read the Scrum Guide: http://www.scrumguides.org/ 2. Try out some of the Tips I’ve mentioned 3. Want to learn more – Attend a course: https://www.scrum.org/classes?country=AU
- 27. ©2016 Avanade Inc. All Rights Reserved. Questions?
- 28. ©2016 Avanade Inc. All Rights Reserved. Keep Calm and Scrum On
Editor's Notes
- http://www.scrumguides.org/
- Ref: https://blog.scrum.org/scrum-myths-scrum-meeting-heavy/ Time boxing – every event in Scrum has a specific purpose and time box. The time boxes are maximum allowed “budgets” of hours. When the purpose of a meeting has been met, end the meeting. If the time box expires without the purpose being met, end the meeting (although the Scrum Master should help avoid this). Scrum events aren’t kept to their prescribed time-box Scrum events lack a clear structure. The team isn’t properly prepared. Meetings not defined in Scrum aren’t minimized. Meetings aren’t fit into the schedule of a developer. Four Week Sprint: 8 hours – Sprint Planning 4 hours – Sprint Review 3 Hours – Sprint Retro 15min per day – Daily Scrum 40hr week x 4 = 160 hrs 4 x 5 x 0.25 = 5hrs 8 + 4 +3 = 15hrs 20hrs of 160hrs = 12.5%
- Ref: https://blog.scrum.org/scrum-myths-ok-sprint-0-design-sprint-hardening-sprint/ Testing Testing including user testing should be done within the boundary of the sprint… otherwise you don’t have potentially releasable software each sprint. e.g. Undone work, DoD can help you here.
- Ref: https://blog.scrum.org/scrum-myths-daily-scrum-status/
- Ref: https://blog.scrum.org/sprint-review-not-phase-gate/
- Ref: http://www.slideshare.net/ColomboCampsCommunity/ilan-goldstein-scrum-myths-42-keynote
- Ref: https://blog.scrum.org/what-is-your-frustration-with-scrum/
- Ref: https://web.archive.org/web/20141007231026/http://www.cedur.se/goal-scrum-master-make-unneeded/ https://www.mountaingoatsoftware.com/blog/does-being-a-scrummaster-get-easier-over-time
- Ref: http://www.slideshare.net/ColomboCampsCommunity/ilan-goldstein-scrum-myths-42-keynote https://www.mountaingoatsoftware.com/blog/rely-on-specialists-but-sparingly
- Ultimately, try out the User Story format… if it works for your team and provides value, then keep it. If it doesn’t, then try something else.
- Ref: https://www.mountaingoatsoftware.com/blog/who-can-add-items-to-the-product-backlog Good ideas can come from anywhere! The Product Owner should prioritize what the team works on!
- Ref: http://www.slideshare.net/ColomboCampsCommunity/ilan-goldstein-scrum-myths-42-keynote "The team commits to do their best" BOOK: Agile Project Management by Ken Schwaber
- Ref: https://blog.scrum.org/commonly-observed-scrum-myths-mysteries-misconceptions/ It’s a myth that the success of the team can be measured by an increase in the team's velocity. Velocity is neither good nor bad, it’s a metric for capacity and is useful for planning how much work a team can forecast to deliver e.g. A Development Team’s velocity may vary dramatically from one Sprint to the next. Perfectly healthy. It is neither good nor bad, velocity just is. This is very hard for many people to accept. Velocity cannot be “improved”. Velocity just “is” Stable is handy for easy planning, but still not “good or bad”
- Ref: https://www.scrum.org/About/All-Articles/articleType/ArticleView/articleId/17/Gone-are-Release-Planning-and-the-Release-Burndown
- Ref: https://www.mountaingoatsoftware.com/blog/the-main-benefit-of-story-points https://blog.scrum.org/why-story-points-for-estimating/ #NoEstimates Monte Carlo simulation The real reason for using Story Points is that they’re accurate. Who says so? Jeff Sutherland, the co-author of the Scrum Guide. In his article on why Story Points are better than hours he puts it like this: Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.
- Ref: https://www.scrumalliance.org/community/articles/2014/december/pros-and-cons-of-modification-in-scrum-ceremonies https://www.implementingscrum.com/2012/01/18/modifying-scrum-you-think-you-know-better/
- TIP: If using VSTS – be sure to select the “Scrum” process template rather than the “Agile” one.