Agile Requirements Information Model (4) – Subset For Agile Programs (a): Features and Feature Backlog

Note: This is the fourth in a series of posts describing, in more rigorous terms, the  Lean, Scalable Requirements Information Model for the Agile Enterprise (AE RIM) that underlies the Big Picture Series. As I’ve noted, I’ve been collaborating in this series with Juha-Markus Aalto, Director of Operational Development for Nokia S60 Software Unit, where a variant of the model is being developed and applied on a large scale (very large- affecting thousands of practitioners) development project.

In the last post, the Subset for Agile Teams we described the model as it applies to Agile Project Teams. In this next post, we move up one level in the Big Picture (see graphic below) and describe how the model is applied at the Program Level.

Agile Enterprise Big Picture with Program Level Highlighted

Agile Enterprise Big Picture with Program Level Highlighted

But first, for convenience, we’ll take a quick look again at the base model.

Base Requirements Information Model

Base Requirements Information Model

Note: as the model is being elaborated in earlier posts, it is being refined with additional model elements and relationships, but I’ll continue to use the summary version (base) model here for simplicity.

The Program Level.

As can be seen in the Big Picture, we assume that a significant number of Agile Teams are collaborating in a Program building an enterprise-class System of substantial complexity. We described the teams use of a quintessentially agile model subset (Story, Task, Backlog Item and Acceptance Test) in the last post.  At the Program Level, we’ll introduce the additional elements of Feature Backlog Item (in this case, Feature backlog item) and Non-Functional Requirement.

capture-program-elements-highlighted

Feature

In describing the features of a product or system, we leave the world of small team agile (where most everything is a Story) and take a more abstract and higher level view of the system of interest. In so doing we have the security of returning to a more traditional description of system behavior. There is certainly some comfort in knowing that while agile changes most everything, it needn’t change absolutely
everything we have learned prior, including what has been well described in software requirements texts (for example: Managing Software Requirements: A Use Case Approach: Leffingwell and Widrig). In that text, Features were described as:

Services provided by the system that fulfill a user need.

They lived at a level above software requirements and bridged the gap from the problem domain (understanding user needs) to the solution domain (specific requirements intended to address the user needs) as the graphic below shows:

"Requirements Pyramid" from Managing Software Requirements, by Leffingwell and Widrig, Addison-Wesley 2003.

"Requirements Pyramid" from Managing Software Requirements, by Leffingwell and Widrig, Addison-Wesley 2003.

We also posited in that text that a system of arbitrary complexity can be described with a list of 25-50 such features. (Note, however, that in the Big Picture, Features are sized to fit within release boundaries, so that a release can be described in terms of a list of just a few features).

That simple rule of thumb allowed us to keep our high level descriptions exactly that, high level, and simplified our attempts to describe complex systems in a shorter form. Of course, in so doing we didn’t invent either the word “Feature” or the usage of the word in that text. Rather, we simply fell back on industry standard norms to describe products in terms of, for example, a Features and Benefits Matrix that was often used by product marketing to describe the capabilities and benefits provided by our new system. By applying this familiar construct in agile, we also bridge the language gap from the agile project team/product owner to the system/program/product manager level and give those who operate outside our agile teams a traditional label (Feature) to use to do their traditional work (i.e. describe the thing they’d like us to build).

Even more conveniently, we also provide a surface to organize agile teams around – the Feature Team, which is an agile team organized for the purpose of delivering a set of features to end users – see Larmon & Vodde-Scaling Lean and Agile Development, Highsmith- Agile Project Management and Leffingwell-Scaling Software Agility. (Note: in my latter text, though, I described teams more commonly as agile component teams, but noted that these teams could be organized around Features, Components, Subsystems, or whatever made sense to the system context).

Whether by serendipity or intent, the ability to describe a system in terms of its proposed features and the ability to organize agile teams around the features gives us a straightforward method to approach building large-scale systems in an agile manner.

The Feature Backlog

Returning to the Backlog and Feature model elements:

capture-backlog-and-feature-highlights

We can see two obvious implications.

  1. Features are realized by Stories. At release planning time, Features are decomposed into Stories, which is the team’s implementation currency. (In a large system, there may tens and even hundreds of Stories necessary to realize a Feature)
  2. Planned Features are stored in a Backlog, in this case the Feature (Release) Backlog.

In backlog form, Features are typically expressed in bullet form, or at most, in a sentence or two. For example, you might describe a few features of Google Mail something like:

  • Provide “Stars” for special conversations or messages, as a visual reminder that you need to follow-up on a message or conversation later.
  • Introduce “Labels” as a “folder-like” conversation-organizing metaphor.

Expressing Features in Story Canonical Form

As agilists, however, we are also comfortable with the suggested, canonical Story form described in the last post:

As a <role> I can <activity> so that <business value>

Applying this form to the Feature construct can be also to help focus the Feature writer on a better understanding of the user role and need. For example:

As a modestly skilled user, I can assign more than one label to a conversation so that I can find or see a conversation from multiple perspectives

Clearly there are advantages to this approach. However, there is also the potential confusion from the fact that Features then look exactly like Stories but are simply written at a higher level of abstraction. But of course, that’s what they really do represent!

Testing Features

In the last post, we also reintroduced the agile mantra all code is tested code and illustrated the point with the base model:

capture-stpry-with-acceptance-test

This illustrates a Story cannot be considered Done until it has passed one or more acceptance tests.

At the Program level, the question naturally arises as to whether or not Features also deserve (or require) Acceptance Tests. The answer is, most typically, yes. While story level testing should assure that the methods and classes are reliable (unit testing) and the stories suits their intended purpose (functional testing) , the fact is that the Feature may span multiple project teams and many, many (tens to hundreds) of stories.

While perhaps ideally, each project team would have the ability to test the Feature at the system level, the fact is that that is often not practical (or perhaps even desirable – after all, how many teams would we want to continuously test the same feature!). Many individual project teams may not have the local resources (test bed, hardware configuration items, other applications) necessary to test a full system. Moreover, at scale, many teams are developing APIs, infrastructure components, drivers and the like based upon the architecture of the solution, and they may not even have an understanding of the full scope of the system Feature that drove their Story to exist. (If you don’t believe or agree with this, test the hypothesis by asking some newly hired teammates working on a new feature or component of a really big system to describe how or why a system-level feature works……).

In addition, there are also a myriad of system-level “what if” considerations (think unified process alternate use-case scenarios) that must be tested to assure the overall system reliability and some of these can only be tested at the full system level.

For this reason, Features typically require one or more functional acceptance tests to assure that the Feature meets the user’s needs. In practice, many of these tests may be implemented at a higher level in the hierarchy, at the Big Picture System Team level. (see below)

system-team1

To reflect the addition of Acceptance Tests to Features, it is necessary to update the information model with an association from Feature to Accetpance Test as the grpahic below shows.

Revised Information Model, Adding Acceptance Tests to Features

Revised Information Model, Adding Acceptance Tests to Features

In this manner, we illustrate that every Feature requires one or more Acceptance Tests, and a Feature cannot be considered Done until it passes.

Next- Nonfunctional Requirements in Agile

Well, that covers the Feature model element at the Program level. However, we have yet to explore another critical Program model element, the Nonfunctional Requirement. Since this post is already way too long, I’ll leave that for the next post in this series.

7 thoughts on “Agile Requirements Information Model (4) – Subset For Agile Programs (a): Features and Feature Backlog

  1. I have a question about definition of the Feature and its cardinality with Epic.

    In the base information model you define Epic – Feature cardinality as (0,1 : 1,*). I read it so that the “Feature” in this context is Epic specific new service required from the system. I would say even that Epic level requirement is refined to Feature level requirements, and further to Story level requirements. On the other hand this Feature in is not a “reusable” system service that may evolve over releases and enable several Epics within and over releases.

    By having this cardinality you end up managing the “new stuff” in backlogs, and can see the effect of the Epic, which I think is good and user requirements driven. However there is now dilemma, what are the reusable services?!

    Have I misunderstood the model? If not, have you considered the relationship between these Features and the existing system services that enable or contribute in enabling several Epics – and are also often called as Features. How should we relate the legacy Features and the Epic specific new Features?

  2. Markku,
    I’m not sure I understand the question, but:
    1) when a new feature appears in the backlog, it stays there until implemented
    2) once implemented, it is, as you say “a continuing service”. If it has user impact, it is documented there. (Otherwise, where the text description of the feature “goes” after that is really a tooling/documentation question, not a method one)
    3) acceptance tests for the feature (and tests for all its constituent stories) continue as part of the regression suite, to assure the feature continues to perform (when it no longer has visibility in the backlog.)

  3. Thanks for your response. I try to clarify my point.

    I mean a case where we have an existing feature baseline, and the new ‘function X’ (needed by the new ‘Epic A’) could be considered as an addition to existing baseline Feature Z.

    I understand the base information model so that a new Feature X is created for the new function X (i.e. the Feature under the Epic A is Feature X, not the Feature Z). In other words, I think that the information model means that you always define new Features instead of trying to identify and change existing Features (by adding Stories under them to fulfill the needs of the new Epic). Is this correct interpretation?

    I think that, at some point of time, in order to have manageable amount of features (for describing the product content) we should merge closely related old and new features. In this example merge the functionality of the Feature X to Feature Z (create a new version of Feature Z description).

    I think that there are two options. We could consider both Features as same information type and merge them, but only after the Feature X is implemented (in order not to mix the new function X and existing functionality of Feature Z). However then we would loose the information that the function X of the Feature Z was added by the Epic A. The other option would be that we consider the “new features” and the “baseline features” as different information types, and only trace them.

    I am thinking that the Epic, Feature, and Story in the base model are sub types of a generic concept ‘Requirement’, on different detail / abstraction level. The “baseline Feature Z” I would keep as a different object type, but I’m not sure which one I should call “Feature”.

    I hope this explains more of my thinking, and the problem I have in understanding the “Feature” and its cardinalities in the base information model.

  4. Thanks Markku,
    I understand the question better now. I think what we are seeing is an (unfortunate but perhaps unavoidable) overload of the term “Feature” here.

    In the information model, we are using the term to describe significant new user value increments (bigger than a story, and fits (by force if necessary!) into a PSI timebox). Once implemented, the feature persists in the system as a service.

    However, from a product description perspective perspective, the same word could be used to describe the same thing, differently. Here’s an example.

    In our model, we might describe and implement labels for our gmail example as as follows:
    Feature 1: Introduce basic google labels (Release 1)
    Feature 2: Introduce color for labels (Release 2)
    Feature 3: support labels on mobile 2.0 browser. (Release 3)

    And yet, to product marketing it will just be “conversation labels” for ever more. Neither usage is right or wrong, it’s just different uses of the term.

    However, it also the case that labels could evolve via new stories without new feature increments being called out. The only disadvantage to that might be the concern that the stories would be less obvious at planning time, and therefore the feature prioritization used for release planning might be strained. But it is no big deal either way.

    In my experience, much of the work in a release (2–30-40%) comes from the teams existing story backlog like the above, we just use the Feature label to drive larger items into the release plan. Also, its a far more comfortable label and level of abstraction for product managers/marketers who drive release content.

    –Dean

  5. Fantastic post and commentary! I agree completely with the information presented. In our world, we use a “spirit of the feature” concept during release planning. We have acceptance criteria at the feature level that helps clarify the commitment(s) made by the teams during the planning session.

    This does a few things for us
    * Helps provide clarity at the feature level what acceptance means from a Product Owner (or other) perspective
    * Gives the iteration team autonomy to execute in the manner they see most fit. They can add stories, remove stories, change stories without an approval process so long as they honor the “spirit of the feature”. If their change impacts that spirit, they involve additional people to ensure proper impact / communication is managed
    * Example: Provide a nice way to interact with downstream teams (training, release management, operations) typically accustomed to waterfall type execution. By default they will want to understand in detail why a story failed). The answer is they shouldn’t care as long as the story gets done by the end of the release!

    In addition, the feature level also helps better articulate what is occurring in a release in a manner that clients and executives care about and understand!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s