Tailoring Vs Waivers / Exceptions

S.No	Tailoring	Exceptions / Waivers
1	Accounting of an SDLC activity in an alternate method.	Justification and approval for required SDLC activities to not be performed on a project.
2	Allows the standard guidelines to be modified to fit the need of the individual project.  Provides flexibility in standard processes.	A formal exemption from the specific activities beyond standard guidelines. Allow software development processes to be adapted to meet the needs of individual projects.
3	Example of Process tailoring Project request document is not documented in the standard SDLC template, instead documented in project inventory repository or part of the scope document.	Example of process waivers  Unit test plans and cases will not be documented for the project. Team accepts the risk of not documenting the test plans and cases.

Business Requirements Vs System Requirements

S No	Business Requirements	System Requirements
1	Business requirements are criteria in order for the software to be successful in meeting the user needs. Generally they focus on the “what” not the “how”.	System requirements address the “how” associated with the business requirements (the “what”).
2	Business requirements concern the business.	Software requirements concern the software solution to the “problem” stated in the business requirements.
3	Business requirements defined as benefits of the business desires.	Software requirements define what the solution must do (or be) to assure the business requirements.
4	Business Requirements are goals and targets the business wants to achieve. Examples:  No: 1 jobs consultancy company	System Requirements are technical goals  Example: Implement web based job portal.

Benefits of traceability Matrix

• Demonstrate the relationship between the requirements to the system.
• To ensure the design is based on established scope, business requirement or functional requirements.
• To ensure that the design documents are appropriately verified, and that functional requirements are appropriately validated.
• To track the requirements changes and their impact to the system
• To demonstrate the system built met the functionality of the customer, end users needs and expectations.
• At faster rate can trace back to the functionality/design/test cases, if there is means of any defect/changes to the system.

Mapping SCRUM Methodology with ISO 9001:2008 standard

There is always a question in the forum, is it SCRUM methodology practices can be mapped to ISO 9001:2000 standard. The answer to the question is yes, we can. The mapping of the SCRUM Methodology to ISO 9001:2008 is as below (please correct me if am wrong in the mapping):

Role	Duties	Artifacts	ISO 9001:2008
Product Owner	Sprint Planning Sprint Review	Product Backlog User stories	Clauses: 4.2.3, 4.2.4, 5.2, 7.1, 7.2, 8.3, 8.5.2 & 8.5.3
SCRUM Master	Sprint Planning Daily Standup Meeting Sprint Review Retrospective Meeting	Sprint Backlog Burn-down Chart	Clauses: 4.2.3, 4.2.4, 5.5.1 5.5.3, 7.1, 7.3.5, 8.2.1, 8.2.3,8.2.4,  8.3, 8.4 & 8.5
SCRUM Team	Sprint Planning Daily Standup Meeting Sprint Review Retrospective Meeting	Sprint Backlog Burn-Down Chart	Clauses: 4.2.3, 4.2.4, 5.5.3, 7.1, 7.3, 8.2.1, 8.2.3, 8.2.4, 8.3, 8.4, 8.5.2 & 8.5.3

How Risk Management is implemented or managed in SCRUM?

For any management (Project, Configuration, Change and etc…) to implement in any methodology we need to identify during the initiation of the project. Same thumb rule is applied here in SCRUM.

Majority of the projects are failed due to the poor understanding of the requirements. Communication between the client and development team is missing in the traditional methodology i.e. effective communication. Interim the client won’t involve in the development process at all once he/she had given the requirements. This is flaw in the methodology is overcame in the SCRUM. That’s the success key of the SCRUM.

Also during the SPRINT planning meeting, the team gets clear view of what they need to develop and what are the acceptance criteria to fulfill the requirements? Details study of the requirement is done during the initial discussions, which leads effective estimation. So the misunderstanding of the requirements and acceptance criteria, the greater risk is addressed in well to do manner.

As we said in the earlier post, the Assumptions, Constraints, Dependencies, Communication, Reviews, Plans are well established and executed in the systematic manner. This leads to quality product.

Also if the team faces any issues during the execution, he/she may raise it during the daily standup meeting and logged as impediments. It’s responsibility of the SCRUM master to address this issues / impediments before they turn as risk for the project.