Technical Debt in Scrum - How to Pay Them Back

A lot of Scrum teams face the challenge of balancing the implementation of new product features and keeping the code base clean and maintainable. Very often the product owner pushes the development team to ship an increment with new features at the end of every sprint. The development team might not find the time to keep the code base clean and maintainable. With every refactoring that the developers feel a need for but that is not done, the team increases its technical debt. If the technical debt is not payed off, it will slow down the team's productivity in the long run. In this post I propose a way of balancing the implementation of new product features and the reduction of technical debt.

A Scrum team pulls work off the product backlog (PB). The PB is maintained by the product owner. To enable the development team to work on new product features and the reduction of technical debt

I propose the use of another backlog: the technical debt backlog (TDB). The TBD is maintained by the development team. Every time a developer feels the need for a refactoring and is not able to do it, she adds an item to the TDB. The development team gets together at least once per sprint to groom the TDB. They present the items to each other, estimate and prioritise them. The estimation can be done with the planning poker technique. During sprint planning 1 the team pulls items from the product backlog and the technical debt backlog.

The use of a separate backlog for technical debt has the following advantages:

• technical debt is visible to the development team and the product owner
• the reduction of technical debt is seen as part of product development
• the development team is engaged to increase the value of its code base

What is your approach to reduce technical debt? Or even better: how do you avoid technical debt?

How to write a unit test for your iOS app

Here are some general guidelines that I am sticking to when I write a unit test for an iOS app.

Unit tests for your System Under Test (SUT) go into a file called SUT_Tests.m. This file contains a class called SUT_Tests. Replace SUT with the class you are testing; e.g. WebService_Tests.

This class has the following features:

• Inherits from XCTestCase
• Has no header file. The class declaration goes into SUT_Tests.m.
• Declares the SUT's private properties and methods in a category called Testing
• Has no private methods. Unit tests should share as less code as possible - they need to run in isolation. Having private methods tends to sharing state among unit tests which breaks isolation.
• Has short methods. Try to stick to a maximum of 15 lines per test* method. If you need more lines, try to break up the method that you are testing or handle cases like testing a method with nil and @"" in separate methods. 
• Methods have self explanatory names. E.g. testMethodXYWithNil, or testMethodXYWithEmptyString

When writing your tests, keep the FIRST principle in mind.

You can use this as a template:

#import 
#import 
#import "SUT.h"

#pragma mark - private declarations

/*
 * Declare your SUT's private properties and
 * methods in this category.
 */
@interface SUT (Testing)

@property (nonatomic, strong) id aPrivateProperty;

- (BOOL) aPrivateMethod;

@end

#pragma mark -

/*
 * The class declaration goes into the .m file.
 */
@interface SUT_Tests : XCTestCase

@property (nonatomic, strong) SUT *sut;
@property (nonatomic, strong) id   sutMock;

@end

#pragma mark -

@implementation SUT_Tests

- (void)setUp 
{
    [super setUp];
    
    self.sut     = [[SUT alloc] initWithDesignatedInitializer]];
    self.sutMock = OCMPartialMock(self.sut);
}

- (void)tearDown 
{    
    [self.sutMock stopMocking];
    
     self.sutMock = nil;
     self.sut     = nil;
    
    [super tearDown];
}

#pragma mark - tests

/*
 * Your unit tests go here.
 */

- (void)testYourSUT 
{

}