Practical Scrum

Scrum

From WIKI, Scrum is an iterative incremental framework for managing complex work (such as new product development) commonly used with agile software development. Although the word is not an acronym, some companies implementing the process have been known to spell it with capital letters as SCRUM. This may be due to one of Ken Schwaber’s early papers, which capitalized SCRUM in the title.

Scrum is an art to manage and execute the projects. Scrum guide us how we can utilize the team strength in best manner to make small and quick deliveries by considering client priorities.

Earlier we used to follow the waterfall model. This model was good to cater to stable requirements when client was not having very complex and changing requirements. But as we grow, client becomes more technical and start expecting more from the software. This results in more complex requirements and more quickly changed requirements. Here comes the SCRUM to manage these complexities. So SCRUM

• Is an art to manage and execute the projects
• Asks client to prioritize the requirements based on business demand
• Asks to plan as per client priorities
• Asks team to make quick deliveries as per business priorities
• Asks team to meet daily to have a quick status call with each other
• Advocates empowerment of team rather than control over the team, i.e. share the responsibilities with the team. If team share the responsibility of planning, then it will also share the responsibility for delivery
• Advocates coaching over bossing
• Advocates code over documentation
• Assumes that every team member is mature enough to understand the responsibility and hence team members can choose and own the task 

Exceptions Designing in Applications

Exceptions
Exceptions are used to tell the user of System/API that something wrong/unexpected is happened during the execution.So the points to be considered while designing the exceptions are:

• Message should be clear and meaningful to the user
• Exception should help the user to understand that what might have happened during the execution.
• Low level system internal exceptions should be wrapped in business or user specific exceptions.
• Exception should help user to decide the next steps of operation, so exception should carry the required information like error code, message or reason of the error.
• Message should not be overloaded
• Only that information should be given which is relevant to the user. 
• Extra information may confuse the user without much use. So internal exceptions or stack traces should not be passed to the user.
•  Message should be as per user expectations
• Possible exceptions should be defined using 'Checked Exceptions'.
• There should be no surprise for user, i.e. unchecked exception should not be passed to user generally (runtime exceptions allowed only if system can not sustain with this exception)

Design for Exception Objects

A few information which exception object should carry