Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the wordpress-seo domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/garryhan/public_html/59secondsagile.com/wp-includes/functions.php on line 6114
The Agile Product Backlog - Part 8 of 9 (Video) - 59 Seconds Agile

The Agile Product Backlog – Part 8 of 9 (Video)

The Agile Product Backlog

A 59 Seconds Agile Training Video

This is an Agile Product Backlog training video.

The Agile Product Backlog Part 8 of 9
Continue to Part 9 Below

The Agile Product Backlog

A 59 Seconds Agile Article

This article provides an ‘Introduction to the The Agile Product Backlog‘ and looks to discuss what the backlog is and what role it plays within Agile projects.

A Single Source of Requirements

What does this mean for the Product Backlog? The product backlog is the “single source of requirements”. Refactoring is part of the Definition of Done for each backlog item; refactoring does not need to be planned separately in the backlog.

In the real world, teams may inherit code with a lot of technical debt, or they may not have been disciplined about refactoring. Technical debt can be defined as the longer term consequences of poor design decisions. In a sense it’s like any other debt:

– there ought to be a clear understanding of why it is incurred, and how and when to pay it back.

It’s important to remember that the Product Backlog is not a dumping ground for the Development Team’s technical debt. That debt is owed by the Development Team to the Product Owner, and the stakeholders the Product Owner represents. Here are some guidelines for preparing backlog items for refactoring:

First, Keep refactoring tasks small, which is the “S” in INVEST. Identify a single small component or even a single class as the scope of a refactoring item.

Second, Use metrics as indicators for refactoring targets. Measure code complexity, coupling & cohesion to identify good candidates for refactoring.

Third, Prioritize refactoring backlog items based on the value-to-cost ratio. The value of a particular refactoring item may be known subjectively to the team, or may be indicated by metrics.

Fourth, Define an adequate unit testing standard before starting. Write all the unit tests required to meet the standard before doing the refactoring, and use them to validate component functionality after refactoring.

Fifth, Identify the components and functionality that may be impacted by the refactoring, and create a test plan accordingly.

Sixth, Create automated system-level tests also known as smoke tests, or integration tests in order to validate whole-system functionality, particularly for areas identified in the previous step.

Seventh, Identify any open defects that may be fixed by refactoring. Coordinate with the team on any defect-fixing efforts that might overlap with the refactoring effort.

Eighth, Identify any dependencies between backlog items

– refactoring or otherwise.

Can you find ways to break those dependencies, such as changing the scope of an item, or creating interfaces between components to isolate work in different areas?

Lastly, Do you need help convincing the Product Owner to prioritize the refactoring effort?

Try to quantify the value of the refactoring.

How much would the team’s velocity increase as a result of refactoring?

What reduction in defects would you expect?

Continue Reading —> Next

The Agile Product Backlog

A 59 Seconds Agile Video Animation
The Agile Product Backlog with 59 Seconds Agile

Continue Reading —> Next

User Stories Applied

A 59 Seconds Agile Book Review

User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.

Continue Reading —> Next

The Agile Principles

A 59 Seconds Agile Infographic
59 Seconds Agile - The Agile Principles
The Agile Principles with 59 seconds Agile

Continue Reading —> Next

Agile Scrum Master Training Course

What is Agile? A 59 Seconds Agile Animation Video

Our Favourite Agile Books

We found these books great for finding out more information on Agile Scrum:

Continue Reading —> Next