Archive for the ‘Process Life Cycle’ Category

How Risk Management is implemented or managed in SCRUM?

September 3, 2010 1 comment

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.


How SCRUM Methodology is different from the traditional methodology?

September 2, 2010 3 comments

This is most frequent question we hear in the arena of SEPG. Will try to address it in the forum to the best and appreciate the viewer’s response.

As part of the engineering position SCRUM is no different from normal traditional methodology of SDLC (Iterative method), but the way the project management is implemented in the SCRUM is interesting and appreciable.

In the traditional methodology the managerial position is done by managers, whereas is in SCRUM it is responsibility of SCRUM team to do that. For example in traditional, estimation is done by head or manager where as in SCRUM it is done by team in conjunction with product owner and SCRUM Master during the SPRINT Planning Meeting.

Assumptions, Constraints and dependencies (ACD) are documented by manager but the implementation rate is very low, whereas it is plugged or enable in the SCRUM through the channel of Daily standup meeting.

Communication Plan / Escalation plan is documented in the traditional methodology but the usage of the same is minimal whereas it is implemented effectively through daily standup meeting here in SCRUM.

Sprint Review meeting is the channel through which the acceptance criteria for the product is met in the SCRUM methodology. Also it’s the responsibility of the SCRUM team to demonstrate the product to the product owner and prove that things are done according to the definition of Done (DOD). We mean to say SCRUM team defines the boundary of acceptance criteria during the Sprint Planning, whereas in the traditional methodology no where the team which is going to develop the product involved to define the criteria for acceptance.

Changes during the SCRUM are not allowed is the Thumb rule in SCRUM.

Configuration Management should be take care during the Zero sprinting or during the Sprint Planning a line item, need to be addressed.

Lessons learned during the project are not documented in formal or informal manner in the traditional whereas here it is reported through retrospective meeting in SCRUM.

Implementation of the Risk Management in the SCRUM will post later.

Implementation of QMS (Part4)

October 3, 2009 Leave a comment

Learn From Others & Share Your Experiences

As it was trail or test ride, implement the same across the organization at full fledge, since the procedures / process is matured one now. For implementation of the procedures / process to the full fledge the existing team which is already had used, need to spend time to share their experience with others and help them to get learned.

Quality is a team work rather than individual one.

Implementation of QMS (Part 1)

October 2, 2009 Leave a comment

Define Quality Policy and Quality Objectives

Based upon the vision and mission statement of the organization, the top management will freeze the policy and objectives that need to be managed or maintain to meet its business goal. To be honest if prepared this with value, can measure the performance of the quality management system to great extent, but mostly in order to meet the requirements of the ISO 9001:2008, organizations establish this as a part, without any value or meaning. However it’s depends upon the individual or the organization who defines the same, since ISO 9001:2008 is the generic management system rather specific.

Constraints need to be considered while on working with policy and objective is what need to be done or what need to be managed to meet the business goals. For an example if we are going to define the policy for a startup company (of embedded systems of any particular products). Let us consider its vision statement is “Be leader in the network and embedded arena” and the mission statement will be “Deliver products on time with high quality”.

By combining both the vision and mission statement, came to the conclusion that the company want to maintain it’s delivery with high quality and on time for long run. So putting up this all in a line can say its policy as “Provide solutions & services or Products and services (supplier) that met the expectations of the customer (customer) in terms of Cost, Time and Quality”.

As defined the policy above, need to look into objectives to carry forward this policy. Quality Objectives is the measurable items at the end of the day to know where we are. From the above statement (policy), it’s clear that the measurable objects or items will be schedule, effort and quality (quality may be in terms of Defect Removal Efficiency, Customer satisfaction feedback & on time delivery).

Functional Audit vs Physical Audit

December 16, 2008 2 comments

Functional Audit

Physical Audit


Objective: To provide an independent evaluation of software products, verifying that its configuration items’ actual functionality and performance is consistent with the requirement specifications.



Objective: To provide an independent evaluation of a software product configuration item to confirm that components in the built version map to their specifications.


Audit Requirements:


1. Software Requirements Specification (SRS), System Specification (SS)

2.  Waiver or Deviation List Prepared

3.  Verification Test Procedures Prepared.

4.  Verification Test Procedures Reviewed and Approved.

5.  Verification Test Data and Results Reviewed and Approved

6.  Test Results submitted.

7.  Test Readiness Review completed

8.  Test Readiness Review minutes and open action items from past reviews available

9.  Copy of baseline and database change requests with their associated status accounting records along with all design provided

Audit Requirements:


1.  Approved final draft of the configuration item (CI) product specification.

2.  A list delineating both approved and outstanding changes against the configuration item.

3.  Acceptance test procedures and associated test data.

4.  Findings / Status of quality assurance programs.

5.  Manuscript copy of all software CI manuals.

6.  Computer Software Version Description Document.

7.  Current set of listings and updated design descriptions or other means of design portrayal for each software CI.

8.  FCA (Functional Configuration Audit) minutes for each configuration item.

Process for Bug Life Cycle

June 13, 2008 4 comments

Defect Management

June 11, 2008 Leave a comment