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:

Functional

“Traditional” non-functional

Devops

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.

Figure 1: A New Arithmetic for the Backlog

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.

Related

Israel Gat is Director of Cutter Consortium's Agile Product & Project Management practice and a Fellow of the Lean Systems Society. He is recognized as the architect of the Agile transformation at BMC Software. Under his leadership, BMC software development increased Scrum users from zero to 1,000 in four years. Dr. Gat's executive career spans top technology companies, including IBM, Microsoft, Digital, and EMC.

Discussion

8 Responses to “A New Arithmetic for the Backlog”

We combine static code analysis together with dynamic code analysis to identify code defects. Each code defect is looked up in a time-to-rectify table. For example, time to rectify missing braces in a Java if statement could be something like 15 minutes.

Once all code defects have been looked up, we add up the times found in the table to find the grand total time required to eliminate the defects. In the example above, if you had four instances of missing braces, the overall time to rectify will be one hour (4X15=60 minutes).

Depending on the customer preference, we either apply standard daily rate or use the customer cost data to calculate the monetary equivalent.If the customer advises us the daily loaded cost per person is $800, in the example above we will assign a technical debt value of $100 (800/8=$100).

I can see the value of using a simple number to constrain tech. debt build up. However, having 4 different buckets for requirements seems a bit arbitrary and unnecessary.

As you note, it’s hard to categorise requirements/stories easily, and their value may change dramatically over time, especially if the whole timespan for the application includes validating the market itself with early iterations. In such a situation, the future value of some types of technical debt would require a Real Options analysis to account for them (eg to assess the value of scale up rates of change, you’d need to assess the likelihood of needing to scale up at a particular rate, which is not known at the start.

If you don’t take the variation of the cost of tech debt types over time, you could over/under invest in them as the application progresses through its life.

So, why not just use the current value of all stories and not bother to categorise?

The proliferation of new types of requirements/stories is something that we experience a lot. These days we primarily see technical debt stories and devops stories. The stories are very different in nature from the “traditional” stories we used to see. So, it is not the tagging of the source of a story that makes the difference. Rather, it is the inherent nature of the story that matters.

To give you an example from a recent Cutter engagement, the general manager of a division we were working with was expecting a certain level of investment and effort to go toward technical debt reduction. After a few months I reported to her that this was not happening. To her question “how do you know?” I simply answered “I see no technical debt stories in the backlogs.”

From what I can see now, my hunch is that “partner stories” might be the next category to emerge. The value chain of just about every company I work with is changing faster than I could say “value chain.” These changes lead to the emergence of stories that are quite different from typical functional stories. Moreover, grooming of such partner stories can be and often is a very different process from grooming “ordinary” stories.

So, I think the new kinds of stories simply reflect the evolution in the state of the art.

I like this approach, but I do have doubts to which extent this works in practice apart from the model. Valuating epics even roughly might be hard to achieve, even harder breaking it down to feature level and getting numbers for tech debt.

How often did you try this out? Any special circumstances you think this approach was made possible?

Otherwise I might think about it as another type of waste due to it’s required effort.

A major Business-IT misalignment we often experience in Cutter engagements is that the client’s financial data is only available at too high a level. The business case projects a value of (say) $100M. This value is divorced from reality in the trenches because it is not broken down to what the operational level needs – value at the epic and story levels. Hence, grooming of the backlog is done (as far as value is concerned) as a swag – “I think this story is more important than that story, etc”

The major piece of work required for calculating value at the epic and story levels is the development of financial guidelines for so doing. In essence, it is not really different from the guidelines used by the financial analysts to determine value at the business case level. Once such guidelines have been developed, their use on an on-going basis could become a standard operating procedure.

Whether calculating value at a granular level is a good investment or a waste of time is a matter of the client’s regulatory environment, economic model, competitive strategy and philosophy of operation. For example, a clients that wants its teams to focus with singularity of purpose on the programming challenge might find the proposed approach attractive as the decision which story to pick next is very easy when value is explicitly stated. Another client might indeed be of the opinion “not worth the hassle.”

A consistent practice in Cutter Agile engagements is to let the client determine what practices will or will not be a good fit for the specific situation at hand. For example, I usually recommend to clients who roll out Scrum to introduce “bouncers” to shield the Scrum teams from interruptions. I have plenty of data demonstrating why doing so makes perfect economical sense. However, if the client says “can’t afford it,” this is final decision as far as I am concerned.

In other words, I will go in depth with my clients over the pros and cons of the Agile practices I recommend. But, the decision which ones to pick is ultimately the client’s. Ditto for the scheme proposed in this blog post.

Brilliant post for me. Coming from a place where technology is an enabler (Internal function) rather than a business, I can see this burn down model providing great transparency to Business Sponsors (Value), Business Stakeholders / Users(Cost) and Technology (TD) in one simple visual.

Categories

About the Blog

The Cutter Blog is an offshoot of Cutter Consortium, a boutique IT and Business Strategy consulting firm located in Boston, MA. Cutter's worldwide network of consultants offers clients analysis of the lastest industry trends, customized consulting and executive education opportunities.

Offering more than just a quick fix -- our size and focus allows us to "get deep" into the challenges faced by our clients so we can provide real and lasting solutions. Want to know more? Visit www.cutter.com.