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 www.scrumstudy.com/blog

Advertisements

How does Scrum deviate from tradition?

The emphasis in traditional Project Management is to conduct detailed upfront planning for the project with emphasis on fixing the scope, cost and schedule – and managing those parameters. Traditional project management may at times lead to a situation where the plan has succeeded yet the customer is not satisfied.

The Scrum Framework is founded on the belief that the knowledge workers of today can offer much more than just their technical expertise, and that trying to fully map out and plan for an ever-changing environment is not efficient. Therefore, Scrum encourages data-based, iterative decision making. In Scrum, the primary focus is on delivering products that satisfy customer requirements.

To deliver the greatest amount of value in the shortest amount of time, Scrum promotes prioritization and Time-boxing over fixing the scope, cost and schedule of a project. An important feature of Scrum is self-organization, which allows the individuals who are actually doing the work to estimate and take ownership of tasks.

Note: The Scrum specific terms used in this article are as per the Guide to the Scrum Body of Knowledge (SBOKTM)  for more  visit: http://goo.gl/UQo6Pe

Is Scrum Master a full time role?

It is not uncommon in a Scrum Master training classes to encounter questions such as “Is being a Scrum Master a full time role?”, or “How much time does a Scum Master contribute towards his role?”, or “Can a person from the development team multitask as a Scrum Master?”

New Scrum Masters might be apprehensive about the role that they might play as future Scrum Masters. However, certified Scrum Masters need to truly understand the responsibilities of a Scrum Master to realize the vital role played by them. The success of a Scrum project rests equally on the shoulders of the Product Owner, the Scrum Master, and the Development team. While the Product Owner and the Development team have their clearly established roles and responsibilities, it might seem that a Scrum Master performs only support roles such as coordinating meetings, removing impediments that are plaguing the team, or shielding the team from interference from the Product Owner.  This might make the Scrum Master seem like a glorified nanny.

Even organizations too sometimes view the Scrum Master role as a part time role. There can be several reasons why Scrum Masters are part time roles. The organization might be short of human resources to have a dedicated Scrum Master or the organization does not consider the Scrum Master’s role worthy of a full time role.

There is an obvious conflict if a developer also performs the role of a Scrum Master. This takes away the objectivity that is required in a Scrum Master while dealing with issues related to the Product Owner or even internal conflicts.

So, let’s focus on the issue where the role of Scrum Master is not considered substantial enough to be a full time role. Sprints in Scrum, unlike stages in waterfall, are intensive periods of activity where development takes place. Any impediments that are not resolved immediately can have an effect on the success or failure of a sprint. The Scrum Master not only resolves impediments as and when they arrive, but also has keen foresight to spot potential issues and create an environment that can help avoid any issues to occur.

The Scrum Master undoubtedly assumes the role of a leader. He coaches and mentors team members both at an individual and a group level to get the best out of the team. He also ensures the team collaborates smoothly and the team delivers what they committed to.

It might seem that a Scrum Master’s responsibilities are vague and general. However, most of the Scrum Master’s responsibilities are performed behind the scenes that require a strong understanding of multiple dimensions such as people, domain, and business requirements.

Aacknowledgement: Content borrowed from www.scrumstudy.com (original url:http://goo.gl/UQo6Pe )