When it comes to Agile methodologies, the debate around prioritization of stories based on business v/s technical value is probably too skewed. Functional stories get priority over the quality attributes of a system such as maintainability & modifiability, which get pushed out to later releases leading to expensive refactoring.

This is a two-part post addressing the above challenge. In part 1, I will talk about using Supportability Framework to addresses multiple stakeholder concerns and transform these into features realizing business value. In part 2, I will talk about how to organize these stakeholders’ perspectives into an agile release plan by using multiple smaller views rather than one story board. This post is the summary of the talk we gave at Agile India 2012. The slides can be accessed on SlideShare or downloaded as PDF from here.

Background

Any software system consists of different kinds of abilities, Functionality being one of them. Other abilities include its modifiability, configurability, maintainability, performance etc. When Agile methodologies talk about quick wins, getting something up and running and then iterating from there, or their emphasis on user advocacy, the general tendency is to focus on end users and develop the functional abilities first. Other qualities such as those mentioned above are either treated as technical requirements and pushed low in the story backlog, or left to the competency of the developer.

The challenges in addressing these other abilities (or quality attributes) of the system are:

1. It is difficult to turn them into stories. e.g. how do we create a story to build modifiability into the system?
2. They are often termed as technical stories, and are difficult to associate to a business stakeholder.
3. How and when do we say that the story is “done” – e.g. when do we say that modifiability is tested & ready?
4. How do we associate business value with these stories, so that we can justify the cost of building them?
5. In which iteration or release do we place these stories? When do we say that we are building modifiability into the system?

Ambiguous quality attributes are difficult to put in a development plan

Supportability

Let us start with the story template – “As a [role] I want [feature], so that [value]“. If we take manageability, and try to turn it into a story, the obvious question is – who is the stakeholder? Who are the stakeholders in our system who want manageability. If we can do that, then we can also ask them to define what it means to them. For example to the operations team, it might mean that the system should support SNMP protocol so that they can manage the system using tools they are already familiar with. The business value to them comes from the fact that it reduces the cost of training or the number of resources required to manage the system.

If we analyze the stakeholder concerns closely, we can divide them into three categories – concerns relating to qualities such as performance, throughput, availability etc. These are essentially constraints on the system and the techniques and patterns to realize them are well understood. Similarly, there is another category of concerns relating to the impact of the system on the organization and environment such as the profitability, increase in bottom line etc. There is yet another category of concerns that relate to the stakeholder productivity – such as modifiability, configurability, usability and so on. Supportability addresses productivity related concerns of the stakeholders by converting them into concrete features or other architectural elements.

Stakeholders themselves can be divided into four groups – people who user the system (functional users), people who run the business (business users) using the software system, people who manage the system (operational users) and people who build the system (development stakeholders). They all have certain productivity related concerns in relation to the system – for example, development stakeholders are concerned about the extensibility, testability and so on. Operational users are concerned about manageability, deployability, debuggability etc. Business users are concerned about the modifiability, configurability and so on, while end users have concerns such as usability.

In software development methodologies, particularly Agile, the end users are well taken care of. However, chances are that many of these other stakeholders were not active end users of the system, such as the operational and development stakeholders. Hence they often get neglected. As we identify them, we articulate exactly what feature they want in the system to address their productivity concern, and the business value they derive out of it. The method of supportability can be described as:

1. Identify the stakeholders (across the 4 stakeholder groups)
2. Identify stakeholders’ functions that are impacted by the addition of the new system
3. Describe the productivity scenario as a statement of time, resources or money to be optimized
4. Analyze the scenario using quality attributes to identify features required to realize the desired optimization
5. Add the features to the stakeholder’s storyboard

The essence of supportability can therefore be stated as – how well does the system SUPPORT ALL its stakeholders to do their function more efficiently in relation to the system.

Benefits of this approach are:

1. Other stakeholders who are affected by the system, (but did not have a say in how it is built) are converted into active users of the system. The system now has some features which are meant specifically for them, and they are sponsors for these.
2. The ambiguous quality attributes are converted into concrete stories that can be taken up for development
3. Since each such story is basically a feature into the system, its progress can be tracked, it can be tested using conventional QA techniques and we can say when it is done.
4. Team can estimate the effort, and since the business value is also articulated, we can decide when to build it. We can now say that the story titled “Support for SNMP” will be built in iteration #4, rather than saying “modifiability” will be built in iteration #4.

In Part 2 of this post, we talk about arranging these stories into multiple story boards, prioritization and allowing the system to evolve across all its abilities.

Supportability is a framework we have been using for almost a decade now. Last year, we presented Supportability framework at the 9th Working IEEE/IFIP Conference on Software Architecture – WICSA 2011 at Boulder, Colorado.