Scrum 101 Prezi (need feedback)

Prezi is a slick tool, a co-worker of mine uses it.  A scanned it briefly and noticed a few things to correct.

• The Burndown chart is not a Scrum Artifact.  It is now optional.
• The Scrum Master's role is not to track work.  The Development Team track's progress towards the Sprint Goal.  The Product Owner may track release progress.  But the Scrum Master is not a tracker.
• In your Scrum Framework diagram change 'Finished Work' to Increment.
• Did I miss Backlog Refinement and Sprint Goal?
• Don't mix Acceptance Criteria and definition of "Done".  DoD applies to the Increment.
• User Stories and Acceptance criteria are not part of Scrum, and are optional complimentary practices.
• The Product Backlog is not 'prioritized', it is 'ordered'.  
• Be careful saying that the Product Backlog items are detailed requirements - they don't have to be.  If you are going with user stories, a user story was meant to be a promise for a conversation.
• Is the Sprint Backlog really an agreement between the Product Owner and Development Team?  Perhaps mention the Sprint Backlog is the Development Team's forecast.
• Is the Sprint Backlog only developed during Sprint Planning?  Where else does it emerge?  Can it change after Sprint Planning?
• The Product Increment section needs some work - refer to the Scrum Guide.

With a little work this should help your organization.  All the best,

Chris

This is only my point of view, but this presentation needs a lot more work:

• some slides have too much content (text)
• animations used in that way like now, may not help in understanding what is going on
• graphics and photos are used in a way that might not help with remembering informations provided

I believe that you put a lot of effort and hearth in creating this and with time it will be better (my presentation constantly evolve - inspection and adaptation :) ). I upload for you a part of my presentation (it's in polish, but might help you): https://youtu.be/BNvVA0qGoXA 



And one last word, at the end of the day, it's all up to a presenter who presents topic, sometimes it's enough to bring only a flipchart and you are redy to go :)

Looks like a lot of work has gone into this.  Hope it does what you need it to do.  

A couple of suggestions:

Empirical Process Control Theory - You might want to explain a bit about Empiricism and how it is founded on making decisions based on the information and experience that you have now.  After you make those decisions, you will inspect and adapt as new information is learned.  To me that is the foundation of Agile Software Development Theory.  You do not make decisions based on what could happen in the future or what you might need in the product for a future enhancement. You decide based on what you know now, the experience you have with similar past work and on what you know is the immediate need.

Scrum Values - Courage and Respect also encompass the courage to bring up difficult topics and respect to others to address them.  This is important in a team becoming high performing and self managing. Not sure if you want to include that but I have found it as something that a lot of people don't see in those two values.

Scrum Framework/Process - You state "Prioritized list of what is required: ...".  In fact it should be "Ordered list of what is required:..."  It is a small but important difference.  Sometimes priority is not the best way to order the backlog to ensure that the Development Team is working on the right items to deliver value. The Scrum Guide specifically says "an ordered list".  It is up to the Product Owner to determine the best way to order the items.

Product Owner - They are a member of the Scrum Team so they are available for all Scrum Events (i.e. Planning, Scrum, Review and Retrospective).  They may not be required at all of these events but they should be available as the events are for all of the Scrum Team.  Also, you never mention anything about the Product Owner's responsibility to the Stakeholders. 

Scrum Master - Again, is available for all of the Events and they participate as equals during Retrospective, not just as facilitator. It has already been mentioned by @Chris about the tracking of progress. 

Product Backlog - see previous note about Ordered instead of Prioritized. I don't understand when you state " Identifies the definition of 'done'".  The Scrum Guide states "Product Backlog items often include test descriptions that will prove its completeness when "Done".".  But that is not the same as identifying the definition of done.  It just adds a measure to help prove the item is complete when it also meets the DoD.

Product Backlog Items - "Detailed Requirements" stood out to me but @Chris covered that one. I would also be careful about calling the PBIs tasks. They aren't tasks as much as problem statements.  Tasks are things you do to solve a problem statement.  

User Story - Definition of "Done" is not part of the User Story.  It is something defined outside the scope of a single story.  I suggest you revisit the Scrum Guide for more information on that.

Sprint Backlog - The Development Team owns this in it's entirety.  The Scrum Master plays no part in the prioritization of the items. That is all up to the Development Team.

Let's Develop A Sprint Backlog - You plan looks suspiciously similar to a Microsoft Project Plan.  Why are you breaking it down into hours based on days?  Why not have a list of tasks that have been created in such a way that they can be completed in 1 day or less letting each Developer take on a task during the Daily Scrum based on their availability and skills? You are expecting them to tell you how long something will take but that does not take into account the empirical nature of learning and adapting as you go. 

You have put a lot of work into this but it looks like you may have been referencing an older version of the Scrum Guide.  You may want to revisit the current guide and update this.  The current version of the guide can always be found at https://www.scrumguides.org/scrum-guide.html.  

Good luck.

I agree with all the above comments mostly with Chris and Daniel regarding content. Sorry but, I see a lot of misinformation there. For example you defined time-boxed event as

a period of time during which a task MUST be accomplished

This is wrong !

According to Scrum Guide, "All events are time-boxed events, such that every event has a maximum duration."

It never advocated that the task needs to be accomplished in that duration. The idea is to maximize what you can do during that duration, not forcing to finish the task in that duration somehow. This is great misunderstanding 

All other points made by Chris like Scrum master not responsible to track progress etc are relevant too.