Scrum Methodology Best Practices

yechte's top 10 "Scrum" methodology best practices

          As we continue to improve the delivery of our services deep into 2016, here's a breakdown top 10 "Scrum" best practices that we employ and advocate. We have over-time progressively been adopting these services into our delivery plans, which helps us increase efficiency. Here's the list of some of the little things we do:

          •  Burn down charts can be used to monitor sprint status. Graphical representations are better than tabular list views in planning.

          •  Planning poker is a useful way to determine sprint item finish durations. And using Fibonacci numbers is a good practice for planning poker numbers.
          •  ROI (Return on Investment) values are useful to determine item priorities in a sprint. Planning poker can be used to determine ROI values.
          •  Using a board and simple planning/reporting tools (e.g. excel, sprintometerprojectsimple) are important and enough as process quality equipment.

          •  Scrum methodology does not offer documenting everything, but this does not mean "no documentation". Really needed documentation can be done as required.

          •  Daily meetings must not be longer than 15 minutes. Scrum is an agile methodology and no one needs to listen to other members' problem details. These details may be discussed after the daily meeting with the scrum master with only required subset of team members.

          •  Stand up meeting style is better for daily meetings, to keep meeting short. Also meeting location and time are recommended to be the same for each day.

          •  Product backlog may contain items which will not be developed. According to ROI values, some items may not be developed and this is normal. Product backlog should contain all possible items anyway. Give backlog items ID numbers, to manage simply.

          •  Sprint length (in weeks) changes are not recommended. But according to the sprint retrospective meeting results, sprint week lengths may be changed if there are really important reasons.

          •  6 hours per day is a realistic planning input. Total sprint hour capacity can be calculated as: (number of team members) * (number of sprint days) * 6 hours

          “Greatness can’t be imposed; it has to come from within. But it does live within all of us.” 

          Jeff Sutherland, "The Art Of Doing Half The Work In Half The Time"

          What do you think of our top 10? Do you agree with these practices or would like to recommend better ways for running a Scrum-based project?
          Feel free to share your thoughts and let us know what you think in the comment section below. 

          Nintendo Switch
          Nintendo unveils its new hybrid console