The Agile Product Backlog – Part 7 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 7 of 9
Continue to Part 8 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.

Refactoring in Scrum

Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behaviour. The goal of refactoring is to improve the internal design of code so it is more readable, maintainable, elegant, and simple; in short, it is easier to change.

Refactoring is not a smokescreen for fixing a bunch of bugs. It is not an effort to change functionality. While it may result in performance enhancements, that is not the primary goal. Here are some of the improvements that can be considered for refactoring:

One, redundant code is not actually adding value to the application. It is executed, thus wasting time, but does not actually do anything. This can happen where code was written earlier and it has not been removed. Sometimes it is not even executed, it is just a piece of code that adds to the complexity of the code.

Two, re-use is another quaint software term, describing code that performs a particular function. It can be called or addressed by the portion of the application that needs this service and then exited when the function or activity is complete. This is ideally how good code should be written; it makes testing during development much simpler and is a single point of failure, not iterated throughout the application.

For instance, if you needed a check for financial month end at several parts in an accounting application, you would require just one date routine that you could access to do the date check.

Three, Splitting up Large Sections of Code. Sometimes the source code in an application can go on for pages without any breaks or interruptions. Chances are that this is where cutting and pasting of repetitive code is lurking, as well as redundant code. It is best to split the code into more manageable pieces; calling sub-routines where possible.

Four, Naming Conventions. Maintaining applications where naming conventions are not clear and are poorly labelled can make the application difficult to maintain. Using appropriate and easy-to-understand names is important for the maintenance team, whether it is a variable or a method that is represented.

Five, In-Source Documentation. Some brief comments about what a method or a function is supposed to do can help when it comes to maintaining an application. It could be helpful to add a comment to clarify the logic in a complex function, or to describe the possible options, for instance, in a menu screen.

It is always good to remember that someone else will have the task of maintaining the application you have written, maybe a few years from now.

Six, improving the design of the code. Simpler is better. This applies to coding too. If there is a straightforward way of coding a method or function, do it that way. Complex code has a higher likelihood of error and is harder to maintain. Plus complex code is more likely to contain redundant code. A few comments make it easier to understand the intent of the original developer.

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