The delineation ‘functional vis-a-vis non-functional’ requirements has been used by many/most of us for quite a few years. Useful that it is, I find various Cutter clients needing a more granular delineation. For example, in a recent engagement the client has actually identified the following kinds of requirements:
- “Traditional” non-functional
- Technical debt (TD)
Striking the balance between the four is a tricky business. It is hard enough to generate some kind of (fast changing) equilibrium between the first two. Doing so across all four is a stretch for most teams. It requires good grasp on numerous subject matters. Even if the team includes a member versed in devops and another one who is familiar with technical debt techniques, it might take a long learning curve for the team to develop the cross-domain knowledge required for informed interactions and subsequent meaningful grooming of the backlog.
Colleague John Heintz and I wrestled with the problem in a recent engagement. The heart of the matter in this engagement was ensuring that technical debt stories would not become ‘second citizens’. We proposed treating technical debt as a strategic investment theme. To our way of thinking, technical debt is no different from customary budget allocations to growing market segments, tactical sales opportunities, cost reduction and the like.
The way the scheme works is illustrated in Figure 1. An initiative/business case/theme is launched with an overall budget – both development and technical debt reduction – of $15M, and (an expected) value of $100M. These numbers are broken down to component numbers at the epic, feature and story levels, enabling quick and easy prioritization in every level. To oversee certain aspects of quality, the initiative is also subject to the constraint TD<$5M. As the teams move on from one iteration to another, the level of technical debt is measured. Whenever it rises in a worrisome manner, technical debt reduction stories are added to the next iteration. For example, the first two iterations depicted in Figure 1 show a single technical debt reduction story. The number of stories is increased to three for the next two iterations.
It would be premature to assess the effectiveness of this scheme at this point in time – we simply do not yet have enough experience with it. We will, of course, report how well it works as we accumulate data. Moreover, we are anxious to hear from you and report about it. Do share with us your experience if you choose to implement this scheme in your company.