Agile Zone is brought to you in partnership with:

Cagdas Basaraner is a software engineer graduated from Hacettepe University Computer Engineering department and Information Systems master program (Turkey). He has 5 years of professional experience, and is working on information systems with JEE web technologies. He is also a former developer of information systems with Microsoft .NET technologies and Command & Control (C4I) systems with Java technologies. Cagdas is a DZone MVB and is not an employee of DZone and has posted 23 posts at DZone. You can read more from them at their website. View Full User Profile

10 Scrum Methodology Best Practices

03.23.2013
| 45801 views |
  • submit to reddit
Here is a list of some best practices for scrum:

  • 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 equipments.
  • 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 a day is a realistic planning input. Total sprint hour capacity can be calculated as: (number of team members) * (number of sprint days) * 6 hours
For general information about SCRUM:
http://codebuild.blogspot.com/2011/08/scrum-software-development-methodology.html
Published at DZone with permission of Cagdas Basaraner, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Lukasz Szyrmer replied on Wed, 2013/03/27 - 9:27am

Just wanted to point out that planning poker should only be used to determine the cost side of ROI. Revenue is something the product owner should estimate. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.