Why do leading organizations choose SCRUMstudy?

• Most popular and widely accepted: VMEdu has trained/certified more than 325,000 persons in delivering successful projects. More than 5,000 students are certified by SCRUMstudy each month, and SCRUMstudy has the largest partner network (650+ training companies) for Scrum and Agile certifications.
• Based on Scrum Body of Knowledge (SBOK™ Guide): All SCRUMstudy exams are based on A Guide to the Scrum Body of Knowledge (SBOK™ Guide, 340 pages) developed by SCRUMstudy. The SBOK™ is the definitive and detailed industry guide endorsed by Scrum experts.
• Industry-wide acceptance: The knowledge gained by getting a SCRUMstudy certification is universal in its application and has been applied by organizations in diverse projects spanning an eclectic mix of industries.
• Scalable Scrum: SCRUMstudy's certifications and courses enable delegates to scale Scrum to the Portfolio and Program levels and not just product design and project management.

• Established name in Scrum/Agile certifications: With more than 650+ A.T.P.s globally, SCRUMstudy has the widest network of accredited training companies offering its certifications. SCRUMstudy certifications are widely reputed and accepted by various Fortune 500 companies such as Apple, IBM, HP, Bank of America, AT&T, Dell, Verizon, Lockheed Martin, and PepsiCo. 

VMEdu, the parent organization of SCRUMstudy, provides training in more than 160 countries for 3500+ companies. You can come to know  more about the corporate training benefits from http://www.scrumstudy.com/corporate-overview.asp

Managing Technical Debt in a Scrum Project

One of the guiding principles of Scrum is to develop the functionality of the highest priority to the customer first. Less important features are developed in subsequent Sprints or can be left out altogether according to the customer’s requirements. This approach gives the Scrum Team the required time to focus on the quality of essential functionality. A key benefit of quality planning is the reduction of technical debt.
Technical debt—also referred to as design debt or code debt—refers to the work that teams prioritize lower, omit, or do not complete as they work toward creating the primary deliverables associated with the project’s product. Technical debt accrues and must be paid in the future. Quick-fix and building deliverables that do not comply with standards for quality, security, long-term architecture goals, and so forth.
Some of the reasons for technical debt could be:

• Lack of coordination among different team members, or different Scrum Teams as teams start working in isolation with less focus on final integration of components required to make a project or program successful.
• Poor sharing of business knowledge and process knowledge among the stakeholders and project teams.
• Too much focus on short-term project goals instead of the long-term objectives of the company. This oversight can result in poor-quality Working Deliverables that incur significant maintenance and upgrade costs.

In Scrum projects, any technical debt is not carried over beyond a Sprint, because there should be clearly defined Acceptance and Done Criteria. The functionality must satisfy these criteria to be considered Done. As the Prioritized Product Backlog is groomed and User Stories are prioritized, the team creates Working Deliverables regularly, preventing the accumulation of significant technical debt. The Scrum Guidance Body may also include documentation and definition of processes which help in decreasing technical debt.
To maintain a minimal amount of technical debt, it is important to define:

• The product required from a Sprint and the project along with the Acceptance Criteria,
• Any development methods to be followed,
• And the key responsibilities of Scrum Team members in regards to quality.
• Defining Acceptance Criteria is an important part of quality planning, and it allows for effective quality control to be carried out during the project.

Technical debt may be a very big challenge with some traditional project management techniques where development, testing, documentation, etc. are done sequentially and often-times by different persons, with no one person being responsible for any particular Working Deliverable. As a result, technical debt accrues, leading to significantly higher maintenance, integration, and product release costs in the final stages of a project’s release.
The cost of changes is very high in such circumstances as problems surface in later stages of the project. Scrum framework prevents the issues related to technical debt by ensuring that Done deliverables with Acceptance Criteria are defined as part of the Sprint Backlog and key tasks including development, testing, and documentation are done as part of the same Sprint and by the same Scrum Team.
For interesting articles about Scrum and Agile, visit http://www.scrumstudy.com/blog/managing-technical-debt-in-a-scrum-project/

Importance of Sprint Backlog in a Scrum Project

What is a Sprint Backlog? Is it a baseline, a record or a report? Baseline is a project document, which, defines aspects of the project and, once approved, is subject to change control. It is used to measure project’s actual performance as against planned targets. A record maintains information on the progress of the project. A report provides snapshots of the status of different aspects of a project at a given point of time or for a given duration.
To answer this question, we need to understand what a Sprint Backlog is, its purpose and composition. The Scrum Team creates the Sprint Backlog and Sprint Burndown Chart using the User Stories and the Effort Estimated Task List during Sprint Planning Meeting. During Sprint Planning Meeting, the User Stories, which are approved, estimated, and committed during the Approve, Estimate, and Commit User Stories process, are taken up for discussion by the Scrum Team. Each Scrum Team member also uses Effort Estimated Task List to select the tasks they plan to work on in the Sprint, based on their skills and experience. The list of the tasks to be executed by the Scrum Team in the upcoming Sprint is called the Sprint Backlog.
It is common practice in Scrum that the Sprint Backlog is represented on a Scrumboard or task board, which provides a constantly visible depiction of the status of the User Stories in the backlog. Also included in the Sprint Backlog are any risks associated with the various tasks. Any mitigating activities to address the identified risks would also be included as tasks in the Sprint Backlog. Once the Sprint Backlog is finalized and committed to by the Scrum Team, new user stories should not be added – however, tasks that might have been missed or overlooked from the committed user stories may need to be added. If new requirements arise during a Sprint, they will be added to the overall Prioritized Product Backlog and included in a future Sprint.


Another tool associated with the Sprint Backlog is the Sprint Burndown Chart. It is a graph that depicts the amount of work remaining in the ongoing Sprint. The initial Sprint Burndown Chart is accompanied by a planned burndown. The Sprint Burndown Chart should be updated at the end of each day as work is completed. This chart shows the progress that has been made by the Scrum Team and also allows for the detection of estimates that may have been incorrect. If the Sprint Burndown Chart shows that the Scrum Team is not on track to finish the tasks in the Sprint on time, the Scrum Master should identify any obstacles or impediments to successful completion, and try to remove them. A related chart is a Sprint Burnup Chart. Unlike the Sprint Burndown Chart which shows the amount of work remaining, the Sprint Burnup Chart depicts the work completed as part of the Sprint.
So, it is difficult to categorize the Sprint Backlog as a baseline, record or a report. And as Scrum professes minimum documentation, Sprint Backlog fulfills purposes of more than one project document. For more information on Scrum framework, you can read the Scrum Body of Knowledge (SBOK Guide). It can be downloaded for free in SCRUMstudy website: http://www.scrumstudy.com/download-free-buy-SBOK.asp

Risk mitigation in Scrum

Scrum is a light-weight framework for project management which is used for complex product development in volatile market conditions. With high competition, companies have to develop products fast and innovatively always adding value and greater customer satisfaction. Quick decision-making and prioritization help mitigate risks in a project. The constant flow of new information changes requirements which Scrum is tailored to handle well and risks are turned into valuable deliverables.
The Product Owner starts the Scrum cycle with identifying requirements of the client through a Stakeholder Meeting. It is up to the Product Owner to clearly outline the customer needs and place them in a Prioritized Product Backlog. Here risk plays a crucial role as it becomes essential to determine high risk elements and place them high in the backlog. The sooner these elements are identified and dealt with in early Sprints the better for the success of the project as the possibility of mitigating larger risks diminish with the progress of the project. Here the Product Owner plays a significant role in discussing various elements with the Scrum team and clarifying doubts. Thus the Product Owner gets a great deal of help from the Scrum Team in prioritizing requirements which the team in turn breaks down into definite User Stories and further into tasks.
The involvement of various stakeholders in the project with the technical personnel makes a mark in risk mitigation in Scrum. The “input-development-feedback” mechanism which is continuous in Scrum keeps everything transparent and pitfalls are readily visible. The Prioritized Product backlog is constantly groomed, i.e. it is analyzed and revaluated all the time as requirements change and/or issues crop up as development of a feature leads to finding a new element which demands immediate attention. Scrum as an Agile framework lets you do exactly that – be agile and incorporate changes in short notices. Scrum’s core principle of Empirical Process Control is thus practiced and upheld. In Scrum, planning is seen as an ongoing process and is represented by grooming of the Product Backlog and the Sprint Planning Meeting at the beginning of every Sprint. Unlike traditional waterfall methodologies where planning is detailed and upfront, this Scrum practice zeroes in on the risk factor. Yet, it is not to be taken for granted as active participation is required by the Product Owner, the Scrum master, and the Scrum Team to keep the mechanism running smoothly. Issues not addressed for long durations may turn into potential risks and take up more time and effort to resolve as time passes.
Some of the Scrum practices which help in mitigating risks are:
1. Flexibility of adding and modifying requirements
2. Regular feedback through the iterative nature of Scrum
3. Team ownership of Sprint Backlog items
4. Transparency ensures detection of risks and early communication
5. Iterative delivery reduces investment risk
In Scrum, it is important to learn and practice its basic principles which collectively and naturally help in effective management of risk.

Acknowledgement: The content has been borrowed from www.scrumstudy.com (Original URL: http://www.scrumstudy.com/blog/risk-mitigation-in-scrum/)

What is Empirical Process Control?

When we talk about any process control, we talk about three elements:

1. Input
2. Process (structured set of activities designed to accomplish a specific objective)
3. Output

If inputs and processes are in control and are reliable, we can get reliable outputs (which are generally the case with Waterfall model). The problem arises when inputs and processes cannot be controlled rigidly which generally means that the outputs would be unreliable (the Agile/Scrum scenario). In such circumstances we need to look beyond the waterfall model and focus on Empirical Process Control which simply means you need to look at the outputs more frequently and if it is not as per your liking you go back to inputs and processes and tweak it accordingly.
In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning. Empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Transparency

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture.

Inspection
Inspection in Scrum is depicted through the following:

• Use of a common Scrumboard and other information radiators which show the progress of the Scrum Team on completing the tasks in the current Sprint
• Collection of feedback from the customer and other stakeholders during the Develop Epic(s), Create Prioritized Product Backlog , and Conduct Release Planning processes
• Inspection and approval of the Deliverables by the Product Owner and the customer in the Demonstrate and Validate Sprint process.  

Adaptation

Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing.

 

Acknowledgement: The content is borrowed from www.scrumstudy.com (original blog url: http://www.scrumstudy.com/blog/what-is-empirical-process-control/)