Tag Archives: user involvement

Defect Management in an Agile Environment

 

The purpose of defect management is to identify bugs or defects of the software and provide information to improve the development process.

In Agile, the process of detecting defects works in parallel to the software development process, and once mastered, can prevent a lot of potential problems.

Scrum per se as a framework does not explicitly show you how to handle defects. With scrum you can bring more accountability to the entire project, however  one lacks clarity on how the teams should operate in the process of delivering the software. Some questions that arise are..

…When a bug is found does it become part of the sprint backlog

…What if adding it to the sprint skews the burn-down and makes it harder to meet the sprint goals?

…What by adding defects to the product backlog delays an important fix?

 

 Defect in Traditional Environment

Conventional Waterfall development consists of a system that can be included in the definition of ‘Done’ when it is analyzed, designed, and coded. Development needs to pass the quality testing phase. Bugs and issues detected during this stage are called defects. They are researched and re-tested by the developers before sending for finalization.

However, this method lacks the ability to preven

t the bugs. Developers are required to break down software code and check results. Once completed, they move on to another project and defects in the previous one causes unnecessary delays in the workflows. This adds stress and instability resulting in an impeded development process.

 

Problem Management in Agile Environment

Whenever an error occurs in the user story of a current or past sprint, it should be immediately identified and resolved to maintain  quality. The methodology may vary from one scenario to another. And so here we elucidate few scenarios:

 

Scenario 1: When a Defect is Detected During Acceptance Testing of a User Story:

In most of cases, it is better to detect and fix a problem as soon as it is discovered in the QA testing. When this isn’t possible, the user story should go back to the developer for resolving the defect. It is re-tested several times until the complete resolution of a defect. In this scenario, recording of a defect can also help. The teams stay abreast of the waste that takes place between the phase of development and testing. And metrics can be used for a better problem management.

 

Scenario 2: When the Team Conducts Regression Testing on the Functionality of Software:

Sometimes, developers may conduct a regression testing on the user stories that are already accepted by the product owner. In this story, there can be a defect that needs to be properly tracked and unraveled.

It is always a possibility to create a defect for such issues. However, you should resolve it immediately instead of creating a defect to be tracked.

 

Scenario 3: A Story is Noted as Done Despite Some Known Defects that are Deferred:

In a deferred defect, there lies a sub-feature of a user story that needs full implementation. Here, it is important to create a new story to fix the defect. These may include defects having requirement specifications. In Agile environments, such defects are sized and prioritized according to other factors.

 

Scenario 4: A Defect Found in the Demonstration of a User Story:

In every 2-3 weeks, developers demonstrate user stories to the stakeholders. If something is found to be broken during this demonstration, a defect is created, prioritized, tracked, and resolved for it. However, the issues in the unaccepted stories can’t be marked as Defects. In this scenario, the story isn’t complete and defect can’t be created.

As a matter of fact, follow a well-defined problem management practice to resolve the defects in the software.

In the end, the best way to manage problems is to prevent them from happening.

 

Agile Development: Unfolding 18 Reasons to Active User Involvement

 

Agile methods are lightweight software development processes that employ short iterative cycles, involve users to establish, prioritize and verify requirements, and rely on knowledge within a team rather than documentation (Boeham and Turner 2004).

Within the spectrum of agile web development, user involvement has evolved from being informative and consultative, to a participative approach. A significant need that weaves together this story is: customer focus. What matters to project teams is:

  • All actions provide tangible business value.
  • The customer is not defined as the project stakeholders of the company, but the end users as well.
  • The degree of alignment between different user roles (an entity that will be using the software directly or indirectly) and their expectations in the development of the software project.

Read more to understand the 7 Core Principles of Agile Development

However, it is not always possible to advocate interactions that involves external customers directly in the development projects, and that’s when active involvement from project stakeholders become a necessity throughout the journey.

Here are 18 reasons why!

#1 Requirements are clearly communicated with upper management and important stakeholders showing how goals are aligned with the vision at the outset.

#2 Market mechanics help shape ideas.

#3 Perceptions and expectations are obtained from internal and external practitioners in a realistic setting.

#4 Face-to-face interviews, user visits, meetings, brainstorming sessions, and open communication channels such as phones, faxes, emails and focus group discussions drive involvement.

#5 Requirements elicitation are discussed (security, portability, scalability, and scope).

#6 Decisions around time-frame ensure optimum benefit of the involvement.

#7 Collaboration with developers in resolving issues pertain features to be implemented.

#8 Evolving project plans without the need of lengthy documentation.

#9 Responding and providing inputs to product prototypes created by development teams.

#10 When end user groups are involved: liaison between users and IT teams by consulting or interacting to extract their ideas, needs or problems.

#11 Influence practices such as User Centered Design, Usability Testing, User Stories, Putting Usability First (PUF), Usability Engineering (UE) and Participatory Design (PD).

#12 Resolving issues as they come up with different stakeholders.

#13 User stories created at the start of every iteration, and then prioritized to ensure they are completed within the time allocated for that iteration.

#14 Development can be monitored on an ongoing basis.

#15 There is complete transparency.

#16 Both sides of the teams are accountable as they share progress openly every day.

#17 There is complete commitment to the project.

#18 There is a sense of joint effort as responsibility is shared.

At Terra, we embrace agile. Our methodologies are based on iterative development, requirements gathering, and creating solutions that evolve through collaboration between self-organizing cross functional team.