Skip to main content

Scrum 101 Prezi (need feedback)

Last post 11:16 pm December 20, 2018 by Ratnakumar Umavenkata Lekkala
4 replies
04:14 pm December 18, 2018

Please Check out my prezi and give some feedback. I am trying to introduce Scrum to my organization. 

https://prezi.com/view/gWCFnSvjXpm4g9pe34RX/


01:26 am December 19, 2018

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


02:36 pm December 19, 2018

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 :)


04:02 pm December 19, 2018

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.


11:16 pm December 20, 2018

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. 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.