Monday, 1 February 2016

How to Get Scrum Certifications?

Organizations around the globe have accepted Scrum as a primary project delivery framework for their projects, especially when they operate in a dynamic business environment. Growing popularity and acceptability of Scrum has created a great demand for Scrum and Agile certified professionals in the job market.
SCRUMstudy, the global accreditation body for Scrum and Agile certifications, offers a comprehensive certification program with several popular Scrum/Agile credentials. There are no prerequisites for most of the SCRUMstudy certifications, however, it is always helpful to understand the certification hierarchy structure. The diagram below shows you the preferred as well as optional certification to move to the next level.

You can start your certification journey, by taking the free certification on ‘Scrum Fundamentals Certified’. The online course is tailored to help anyone interested to know more about Scrum, learn about key concepts in Scrum as defined in the SBOK™ Guide, and to get a basic understanding of how Scrum framework works in delivering successful projects. Once you complete the course and pass the exam at the end of the course, you will be accredited as “Scrum Fundamentals Certified”. For more details, visit:

Many delegates undergo formal training to prepare for advanced certification exams offered by SCRUMstudy to get hands-on experience of implementing Scrum in real life projects. More than 500 SCRUMstudy Authorized Training Partners conduct certification training and classes globally. All the certification exams are based on the Scrum Body of Knowledge (SBOK Guide) which can be downloaded for free in SCRUMstudy website:

When Conflict Emerges, SCRUMstudy Helps You Manage

You can please some of the people all of the time, you can please all of the people some of the time, but you can’t please all of the people all of the time.
-John Lydgate

In professional sports, whether you’re a benchwarmer or a superstar, when you become a “cancer” it is more likely than not that your days on that team (or in that sport) are numbered. “Cancer” is a label reserved for someone whose behavioral issues metastasize to other areas of the locker room, often triggering team-wide dissension. In these cases, teams routinely trade or release volatile players (as gifted as they may be) for restored harmony in the locker room.
The corporate world is not immune to the workplace “cancer” or occasional discord among colleagues. But organizations applying the Scrum framework encourage an open environment and dialogue. Conflicts among Scrum Team members are generally resolved independently, with little or no involvement from management or others outside of the Scrum Team. In other words, a “cancer” often goes into remission.
Conflict can be healthy when it promotes team discussions and encourages debates because this usually results in benefits for the project and respective team members. It is therefore important that the resolution of conflicts be encouraged, promoting an open environment where team members feel welcome to express their opinions and concerns with each other and about the project, and ultimately agree on what is to be delivered and how the work in each Sprint will be performed.
Conflict management techniques are used by team members to manage any conflicts that arise during a Scrum project. Sources of conflict evolve primarily due to schedules, priorities, resources, reporting hierarchy, technical issues, procedures, personality and costs. Usually there are four approaches to managing conflict in an organization applying Scrum processes: Win-Win, Lose-Win, Lose-Lose and Win-Lose. Let’s take a closer look at each with these discussions from A Guide to the Scrum Body of Knowledge (SBOK).
Win-Win: It’s usually best for team members to face problems directly with a cooperative attitude and an open dialogue to work through any disagreements to reach consensus. Organizations implementing Scrum should promote an environment where employees feel comfortable to openly discuss and confront problems or issues and work through them to reach Win-Win outcomes. SCRUMstudy endorses this approach as the optimal way to manage conflict, and suggests teams regularly resolve to achieve this outcome.
Lose-Win: Some team members may at times feel their contributions are not being recognized or valued by others or that they are not being treated equally. This may lead them to withdraw from contributing effectively to the project and agree to whatever they are being told to do, even if they are in disagreement. This situation may happen if there are members in the team (including managers) who use an authoritative or directive style of issuing orders or do not treat all team members equally. This approach is not a desired conflict management technique for Scrum projects, since active contribution of every member of the team is mandatory for successful completion of each Sprint. The Scrum Master should encourage the involvement of any team members who appear to be withdrawing from conflict situations.
Lose-Lose: In conflict situations, team members may attempt to bargain or search for solutions that bring only a partial degree or temporary measure of satisfaction to the parties in a dispute. This situation could happen in Scrum Teams where team members try to negotiate for suboptimal solutions to a problem. This approach typically involves some “give and take” to satisfy every team member—instead of trying to solve the actual problem. The Scrum Team should be careful to ensure that team members do not adopt a Lose-Lose mentality.
Win-Lose: At times, a Scrum Master or another influential team member may believe he is a de facto leader or manager and try to exert his viewpoint at the expense of the viewpoints of others. This approach is not recommended when working on Scrum projects because Scrum Teams are by nature self-organized and empowered, with no one person having true authority over another team member. Although the Scrum Team may include persons with different levels of experience and expertise, every member is treated equally and no person has the authority to be the primary decision maker.
With any team, conflict is bound to occur once in a while. You can’t please everyone every moment of your life. What is important is the manner in which conflict is managed. Of the four typical approaches to managing conflict, only one involves a win-win scenario. In order for such a scenario to be achieved, organizations implementing Scrum should promote an environment where employees feel comfortable to openly discuss and confront problems or issues and work through them with cooperative attitudes. Oftentimes, such treatment even leads to a cure for “cancers.”
Find more interesting articles about Scrum and Agile at

Original post link:

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

Original Link:

Monday, 11 January 2016

Roles of Scrum Developers in Scrum Project

Scrum developers, also referred to as the development team or Scrum team, are responsible for developing the product and they possess all the essential skills required to carry out the work of the project. They have a high level of collaboration to maximize productivity, so that minimal coordination is required to get things done. To minimize dependency, team members are experts in chosen domain, but also possess basic knowledge and skills about other domains.
Some of the key responsibilities of Scrum developers which they are required to fulfill in any Scrum project are:
  1. Provides inputs for creation of the Collaboration Plan and the Team Building Plan
  2. Ensures a clear understanding of Epic(s) and Personas
  3. Understands the User Stories in the Prioritized Product Backlog
  4. Agrees with other Scrum Core Team members on the Length of Sprint
  5. Seeks clarification on new products or changes in the existing products, if any, in the refined Prioritized Product Backlog
  6. Provides inputs to the Product Owner on creation of User Stories
  7. Estimates User Stories approved by the Product Owner
  8. Commit User Stories to be done in a Sprint
  9. Develops Task List based on agreed User Stories and dependencies
  10. Estimates effort for tasks identified and if necessary, updates the Task List
  11. Develops the Sprint Backlog and the Sprint Burndown Chart
  12. Creates Deliverables
  13. Identifies risks and implements risk mitigation actions, if any
  14. Updates Impediment Log and dependencies
  15. Updates Burndown Chart, Scrumboard, and Impediment Log
  16. Discusses issues faced by individual members and seeks solutions to motivate the team
  17. Identifies risks, if any
  18. Submits Change Requests, if required
  19. Participates in Prioritized Product Backlog Review Meetings
  20. Provides inputs to Scrum Master for Scrum of Scrums Meetings
  21. Demonstrates completed deliverables to the Product Owner for approval
  22. Identifies improvement opportunities, if any, from the current Sprint and agrees on any actionable improvements for the next Sprint
  23. Participates in the Retrospect Project Meeting

Wednesday, 6 January 2016

Scrum Fundamentals

There are lot many ways to develop or code software. Easiest is the one in which no documentation, design or testing is involved. Others describe on how to improve coding, testing etc.

All developers claim that software delivered is better by their method and also is faster with less effort. It sounds really good but everything should have a proof when it comes to software. Although, Agile methods are not at the peak but its growing and getting very popular every day.

However, it’s difficult to prove on whose method of software development is better as there is no scientific uniform data to compare or methodologies like Agile or Scrum. All the projects depend on the skills and knowledge of the people involved in it, domain used, choices made at every stage, process method. This comparison is more like comparing cars to trucks where anyone can easily say: that is not a real car and this neither a truck.

We all know that every project of software is different n by its nature software development is exclusive. It is fundamentally true. There are people who still try to differentiate the effectiveness of methods of software development. It has been proved that there are several different methods and most of them were significant in specific situations.

Also, people promote the methods of software development, which many say is nothing but a way of earning more money by many consultants. Small companies of trainers and consultants get created easily with the help of the certifications and eventually they get busy training the delegates of big companies. It’s always better to take the help when needed moreover nothing wrong in it as it might act as the help you were actually looking out to give the final touch to the project.

Agile is very well known and popular as it give u many best practices, focuses on the job to be done, though we should accept it that it doesn’t happen every time. As far as Scrum is considered, a well-judged product owner’s presence will prove it to be the faster and effective than waterfall approach.

Acknowledgement: The content is borrowed from (original blog url: