10 SCRUM Methodology Best Practices

Here is a list of some best practices about 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, sprintometer, projectsimple) 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 other members' problem details. These details may be discussed after daily meeting with 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

Software Architecture Antipatterns : Swiss Army Knife Interface

Swiss Army Knife Interface is an interface class which has excessive number of method definitions. Architect/designer may design this interface to use for every need of the software, but this is a wrong approach and an antipattern. More than one interface must be designed using some design approaches.

Of course, "excessive number of methods" is a too general statement. Although most developer think that a handful number of methods (e.g. 8-10)  and some studies show that some magic numbers (7 plus/minus 2) are mostly enough, we can't say the maximum number of methods precisely. 

First of all, you must think that this interface will be implemented by a class and if the number of methods is excessive, there will be plenty of empty method bodies in implementor class. But this situation still can't determine the number of interfaces and number of methods in an interface.

The answer is hidden in the OOP SOLID rules. Single Responsibility ("S") rule of SOLID says that "every object should have a single responsibility", and Interface Segregation ("I") rule of SOLID says that "different types of functionalities should be placed in different interfaces". If an interface have more than one types of functionalities or defines more than one responsibilities, implemening that interface is meaningless because implementer class will not suit SOLID rules by implementing that interface. 

More than one Swiss Army Knife Interface may also exist in a software. This means more than one problem exist and must be solved. 

For another viewpoint, you can take a look at our another post about interface segregation principle:

http://codebuild.blogspot.com/2010/09/oop-solid-rules-interface-segregation.html

SCRUM Software Development Methodology : Nuts & Bolts

Scrum is an agile software development methodology. It is useful for relatively small (5-9 developers) development teams and limited project calendars. This post will give brief definitions and useful suggestions about this methodology.

Team Members

• Product Owner: Behaves as real customer and criticizes product. Attends meetings and can determine work priorities. Adds items to product backlog (will be told later). Only one person can be product owner in a scrum team.


• Scrum Master: Enforcer of the rules. Generally most experienced team member. Works like team leader. Solves the problems of the team, if team/team member couldn't. Only one person can be scrum master in a scrum team.


• Team: A scrum team member is responsible of analysing, design, development, test and the other required processes. So, specialization is rare. Self-organization is a plus. There is no hierarchy in members. Scrum master is also a team member.

Document Types:

• Product Backlog: This list contains items that the project must have and may have. Item size can increase every time.


• Sprint Backlog: Sprint is a time interval (generally 2-4 weeks) that a group of items must be completed (similar with "iteration" in unified process and some other processes). Sprint backlog contains items that must be completed in that sprint.

Meeting Types: 

• Daily Scrum/Standup Meeting: Max. time is 15 minutes. Performed at the start of the day and generally in stand-up style. Every member should answer 3 questions: 


• What did you do yesterday? 


• What will you do today? 


• Is there a problem about your work item(s)?


• Sprint Planning Meeting: Performed at the start of each sprint. Sprint backlog is created using product backlog items and priority opinions of all team members.


• Sprint Review: Performed at the end of each sprint. Status of sprint backlog items are discussed and results are recorded.


• Sprint Retrospective: Performed at the end of each sprint. Sprint process issues are discussed to improve process quality.

Process:

Scrum Process

• From product owner opinions and other internal/external sources, product backlog is created.


• Sprint planning meeting is performed at the start of each sprint. Previous sprint's unfinished items (if exists) and product backlog are sources of sprint backlog. Backlog is created according to item priority opinions of all team members. Sprint length (in weeks) may also be defined here for once.


• In sprint time, daily meetings are performed. Team members take responsibility of items from item pool of sprint backlog continiously when an item is finished. By the way scrum master solve possible problems and product owner criticizes results.


• Sprint review and retrospective meetings are performed at the end of each sprint. Results are discussed in these meetings. Results are recorded to be applied for next sprints.