Agile Enterprise Requirements Information Model – Subset for Agile Project Teams

In a recent post, A Lean, Scalable Requirements Information Model for the Agile Enterprise, we introduced the requirements information model that underlies the requirements-related elements of the Big Picture series. While presenting the model in UML form may seem a bit of a geek fest, it’s the best way to describe the model in relatively unambiguous terms. In a follow on post, we described What’s Lean and Scalable about the Model and promised to later describe the model from the perspective of Agile Project Teams, Agile Programs and the Agile Enterprise. In this post, we’ll describe the model as it applies to Agile Project Teams.

But first, here’s a look at the requirements meta-model.


Agile Requirements Information Model

The Model Subset for Agile Teams

In the Big Picture series, the Agile Project Team (Agile Team for short) is highlighted below:


Agile Teams in the Big Picture

The critical role of the Agile Team itself within the agile enterprise has already been described in this post.

In accordance with the lean and scalable principles from the last post, it is a) the simplest thing that could possibly support the needs of all stakeholders and b)  particularly sensitive to the needs of the team members, in that the Agile Team is concerned with only a small subset of the requirements model. Moreover, that subset is quintessentially agile in that the artifacts described are consistent with most agile training (at least Scrum and XP) as well as common practice. (In other words, it isn’t mucked up with administrative overhead, manual traceability, reporting, detailed requirements-cram down, or any of the other ways enterprises can unnecessarily burden the teams!).

The elements of the model that the teams base their work on are extracted from the model and illustrated below:


Since most of the work (90-95%) involved with delivering enterprise software in an agile manner is done by these teams, using only these simple artifacts and relationships, it’s worth the effort to define these items and relationships more explicitly. We’ll do that in the following sections.

Backlog Item

First, we note that Story, pictured in the center, is a “kind of” Backlog Item. (The triangle indicator connecting Story to Backlog item is the UML generalization relationship, indicating that the thing the arrow points to is a generalization of the special case of the pointing thing. In other words, in this case, Story is a special kind of Backlog Item. This also implies that there are other kinds of backlog items as well).

The term Backlog was first introduced by Scrum where it was described as Product Backlog. In our enterprise model, Product can be a pretty nebulous thing as teams may be working on APIs, subsystems or whatever so there are multiple types of backlogs in the Big Picture. Therefore, our use of the term Backlog is more generalized than in Scrum. In the Big Picture, we described the particular backlog we are talking about here as the Iteration (Story) Backlog as can be seen below.


This Backlog is the one and only, definitive, source of work for the team. In this case, this particular Backlog (Iteration (Story) Backlog) holds all the work items (represented as Stories) that the team has identified. It is local to them. It is their repository for all identified work items and the contents are typically of little concern to others in the enterprise. This is a workflow “separation of concerns” which provides the team with a local work sandbox. They manage it, tool it and put things in and out of it as it suits their needs in meeting their iteration objectives. If “a thing to do” is in there, it is likely to happen. If it isn’t, then it won’t.

Note: Within the team, maintenance and prioritization of the Backlog is the responsibility of the Product Owner, who in turn is a full (or maybe half) time resident of the Agile Team. The role of the Product Owner in developing, prioritizing and maintaining the backlog is outside the scope of this post. For more on that role, see posts in the Product Owner and Big Picture 3: Role of the Product Owner category.


The team’s Iteration (Story) Backlog consists of all the work items the team has identified. In the meta-model, we call these work items Stories because that’s what most agile teams call them. (Strictly speaking, “work items” is probably a better term, but we aren’t trying to fight agile gravity with this meta-model!) So for our purposes, we’ll define Story simply as

A Story is a work item contained in the team’s iteration backlog.

User Stories

While that definition is simple, it belies the underlying strength of agile in that it is the User Story that delivers all the value to the user in the agile model. Indeed, the user story is inseparable from agile’s goal of insane focus on value delivery. In the meta-model so far, the User Story is not explicitly called out, but rather is implied (as a shorthand) by the Story class.

To make the User Story explicit, we need to extend the simple model a little as seen below:


With this small addition, we now see that the backlog is composed (primarily) of User Stories and anything that isn’t a User Story is an Other
Work Item. Other Work Items include things like refactors, defects, support and maintenance, infrastructure and team overhead. We’ll discuss the rationale for calling out these Other Work Items specifically later, but for now they appear primarily to help the team’s better estimate the time they actually have to deliver User Stories.

I’ve described the User Story briefly in the post Enterprise Agility–The Big Picture (5): User Stories and the Iteration Backlog, but since this key construct does most of the work in the agile model, it’s worth investing some more words here.

User Story Basics

User Stories are the agile replacement for what has been traditionally expressed as software requirements statements or Use Cases and they are the true workhorse of agile development. Developed initially within the constructs of Extreme Programming, they are now endemic to agile development in general and are taught in most Certified Scrum classes as well. In our model, we’ll define a User Story as:

A User Story is a brief statement of intent which describes something the system needs to do for the user.

As commonly taught (at least in the last few CSM Scrum courses I have seen), the user story takes a canonical (standard) form of:

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

(Note: While searching for the origin of this nifty form, I received the following email from Mike Cohn ” It started with a team at Connextra in London in 2003 and was mentioned at XP2003. I started using it then and wrote about it in my user stories book that came out in 2004″.  Thanks, Mike.)

In this form, User Stories can be seen to incorporate both elements of the problem space (the business value delivered) and the solution space (the activity that the user does with the system). For example: “As a Salesperson, (<role>) I want to paginate my leads when I send mass emails (<what I do with the system>) so that I can quickly select a large number of leads (<business value I receive)”.

LOTS has been written on applying User Stories in agile development. The good news is that it is now so common that I don’t have to elaborate further here, as that is not the intent of this post nor the meta-model. For that, I refer you to the many books on Extreme Programming and User Stories.

Acceptance Test

Ron Jeffries, one of the creators of XP, described what has become my favorite way to think about User Stories. He used the neat alliteration, Card, Conversation and Confirmation to describe the three elements of a User Story. Where:

  • Card represents the 2-3 sentences used to describe the intent of the story.

Note: In XP and agile, stories are often written manually on physical index cards. More typically in the enterprise, the “card” elements is captured as text and attachments in agile project management tooling, but teams often still use cards for early planning and brainstorming.

  • Conversation represents fleshing out the details of the intent of the card in a conversation with the customer or product owner. In other words, the card also represents a “promise for a conversation” about the intent.
  • Confirmation represents the Acceptance tests which will confirm the story has been implemented correctly.

With this simple alliteration and XPs zealousness for “all code is tested code” we have an object lesson in how quality is achieved during, rather than after, actual code development.

Relative to our model, however, we have represented the Acceptance Test as an artifact distinct from the (User) Story itself as seen below:


There are many reasons why we did this, which I won’t belabor here, but in any case the model is explicit in its insistence on the relationship between the Story and Acceptance Test as follows:

  • In the 1 to many (1..) relationship – every story has one (or more) Acceptance Tests.
  • Done when passes. A story cannot be considered complete until it has passed the Acceptance Test(s).

In this manner, the model explicitly supports the agile “all code is tested code” quality mantra. Every User Story has at least one Acceptance Test which must be passed before the Story can be considered to be done. Very direct. Very explicit. Very cool.


And finally, we find our way to the Task model element:


As you can now infer from the graphic, stories are implemented by Tasks. Tasks are the lowest granularity in the model and represent specific work items to be performed by specific team members to accomplish the story. In our context the definition of a Task is:

A Task is a small work item, either stand alone, or necessary for the completion of a Story

Tasks have an owner (the person who is going to do the task) and are estimated in hours. The burn down of task hours represents one form of iteration status. As implied by the 1-to-many relationship expressed in the model, there is often more than one task necessary to deliver even a small story. For example:


In other cases, it’s common to see a mini-lifecycle coded into the Tasks of a Story. For example:

Story 51 – Select photo for upload
Task 51.1 – Define acceptance test     Juha, Dean, Bill
Task 51.2 – Code story                            Juha
Task 51.3 – Code acceptance test       Bill
Task 51.4 – Get it to pass                        Juha and Bill
Task 51.5 – Document in user help    Cindy

In most cases, Tasks are “children” to their associated Story. However, for simplicity, our model also supports stand alone Tasks. With this construct, a team need not create a Story simply to parent such an item as “order 8 Gig more memory for the new file server”.

Well, that’s it for our description of the meta-model as intended to be used by Agile Project Teams. In an upcoming post, we’ll look a little higher in both the Agile Requirements Information Model and the subject organization and describe how to apply the model to Agile Programs.

11 thoughts on “Agile Enterprise Requirements Information Model – Subset for Agile Project Teams

  1. Are you aware of tools that implement (or even come close to implementing) this kind of framework?

    Agilefant ( comes pretty close, but still lacks the Epic -> Feature -> Story -hierarchy (we are working on this). In other words, it has only a single type of backlog item.

  2. Oh, I forgot to mention our current workaround for the lacking hierarchy (and a mapping of Agilefant’s current concepts to this meta model)

    First of all,
    – business themes = portfolio investment levels
    – product themes = strategic product themes

    Then the workaround itself:
    – backlog items on the ‘product’ level => epics
    – backlog items on the ‘release’ level => features
    – iteration goals => committed stories
    – backlog items in iterations => tasks
    – …and hyperlinking iteration goals, features and epics as necessary

    Agilefant is open source and the result of our past years’ research efforts at SoberIT at the ( at the Helsinki Univ of Technology.

    Sorry so much for sounding like a tool salesperson, but after all, it’s Christmas time, isn’t it? 🙂

  3. Dean,
    Nice to see you do this meta model work in the blog. As you know Rally implement this hierarchical breakdown structure for stories and projects. We do not allow you to name the levels of the hierarchy, but those kind of custom labels will make it the the UI in 2009.

    The great thing about Rally is that you can pass the children to other teams and still see the status of them in the epic or the project roll-up.

    Thanks for the good work. I wonder why you have to explicitly name the levels of the breakdown and constrain the breakdown to three levels. (most teams we see only use three levels – and above five is a real exception.)

  4. Thanks Ryan and Jarno,
    I think the hierarchy, WITH its named labels is important. The labels give differing people, differing levels of abstraction to talk about system behaviors with nouns they understand.

    They have been describing systems using Features for years, why try to teach them its a “parent story”? I admit that it’s interesting to teach people at the portfolio level “Epics”, but they do tend to “get” the word and its much harder to describe as a really, really big story or super Feature. Epics become the currency for portfolio investment management, just like stories are the currency for teams delivering iterations.

    As for the number of levels, there is no right answer, but five is what Nokia is using and it seems to work there, on a system of super scale.

    I’ve also used this label/model in smaller contexts (hundreds of practitioners) to very good effect and have seen senior product managers and VPs describing the Top 10 “Strategic Investment Themes” and some supporting Epics for the year.

    Basically, it gives them an agile language they can use to describe what’s important to them. And that should be important to us. That’s why we put the labels and the (relativity) fixed hierarchy, in the model.

  5. I think that proposing a set of labels for (a common set of) levels is valuable, too.

    An infinite hierarchy may be useful, but even more interesting, I think, would be to understand what is the needed “depth” that handles most situations. The less parts that move, the better (for most people, anyway).


    In addition to Rally (and Accept), do you know what other solutions support this kind of hierarchy?

  6. Hi Dean, I noticed that your meta-model is void of Use Cases! That got me thinking “Hmmm…I’m working in an agile organization as an agile product owner, but I still write Use Cases when I feel the need to! I must be still living my former dark, SDLC (pre agile) life…!”

    But, maybe not!

    How about exploring how Use Cases can help as a powerful tool in the agile requirements meta-model? Below is some experience I’ve had with agile use cases.

    First and foremost, I employ use cases as my primary elaboration technique for the simple agile attitude of constant communication. Our team includes software, firmware, and hardware developers. At our mature stage of the game, all stories inevitably touch all developers, across all disciplines. While we would like to think we all agree, inevitably, we don’t. We are constantly having discussions like: “Should the logic be built into the end device, or the software platform”. “Should the data be pushed or pulled?” “What’s the persistence model, and how long/where should the data persist?” “What are the hardware memory requirements for this story?” Use cases help flush out answers to these questions, and help bring a starting “agreement” among developers as to the initial direction of implementation. That said, we are agile, and it’s all subject to change!

    Here’s how we are using use cases in our agile process, and why they work for us.

    Why use cases work in our agile process
    1. Initial Agreement to Final Agreement
    Many Epics or Stories start with a picture or an idea. It’s usually a UI that Product Management has sketched, which defines what the user sees, and infers how the user shall interact with the system. This is often (but not always) accompanied with a story. Defining how the system behaves as a result of the user interaction is the challenge. Use cases provide the perfect forum to analyze and define this initial to final user to system interaction.

    2. Statement of Record
    Like I said, developers do not always agree (nor do humans for that matter). Use cases provide that simple statement of record for when our brains fail to remember how we thought through the main success scenarios and alternate success scenarios, as well as variations and open issues.

    3. Developers Love Them!
    A story is not DONE until it’s tested. Most “good” developers write their unit test before they even start laying down code. (some write them after). Use cases give developers a framework for their unit tests before they get going. That’s not the only reason they love them. Developers are often anal (forgive me, I love developers for this reason). Use cases give developers the opportunity to capture details that they feel are important to the story. Careful though…don’t let them get caught in “analysis-paralysis”. As scrummaster, allow discussions, and come to initial agreement honoring the fact that we don’t know what we don’t know, and move on.

    4. Business groups gain early understanding
    My philosophy is: “Publish everything, and have no secrets.” Our Wiki is golden. By publishing the use cases, all areas of the business gain early access and an understanding of how the system will behave. Stories can provide this same benefit, however, use cases give other parts of your business a “more than they need to know”, aspect, thus covering the proverbial ass and further opening up conversations. Also, this helps get documentation into the agile process early and often.

    5. The perfect framework for user acceptance testing
    Many conversations happen during the agile development lifecycle. If use cases capture the initial to final agreement per sprint and/or release, what a perfect framework for user acceptance tests (Agile Product Owners LOVE THIS!)

    Best Practices for Agile Use Cases
    Interview Stakeholders
    Before you jot down a word, interview Product Management and the development team leaders. Knowing that the team will most likely not agree, this helps in gaining an initial understanding of what the open issues and what discussion points should take place.

    Make them lightweight
    No one wants to read use cases that are dozens of pages long. You’ll gain better readership by keeping them short. No longer than two pages should be sufficient to get going. (two may even be too long!). Capture just enough information to get the heads to nod and move on. Make sure you communicate in a language that is common to all stakeholders.

    Keep detailed UI design out of it
    I struggle with this one, as I am a fond believer in UI detail, but that’s not the goal. Having an exhibit or two with screen shots is fine. Making your use case into a detailed design document is not.

    Present/collaborate with your team
    Use the daily meet-after opportunity to elaborate and gain feedback. This daily opportunity allows for quick turnaround. Depending on the story, developers often need time to noodle on a use case. Asking them daily until confidence is built helps hedge your bets.

    Design them for change.
    A simple intro page with a change traceability table will most likely serve you in the future. (post mortems, refactors, etc.)

    Write your Use Cases Just-In-Time
    After interviewing stakeholders, most Product Owners can kick out a use case in an hour or so. This should happen JIT prior to Iteration Planning. Having a light-weight use case ready at the iteration boundary provides the team a clear framework for tasking and estimating.

    Where could use cases live in an agile requirements meta-model?
    Using your requirements meta-model, I took some liberties and bloodied up where “Light Weight Use Cases” could live. Note: they are optional!

    Light Weight Use Case inserted into Requirements Meta Model

    All this said, stories are part of our daily agile process too! Not all stories are elaborated with use cases. Some are clear as a sunny Colorado day. Use cases are brought into the agile process primarily when we want to provide that more detailed analysis of user/system interaction, and gain agreement across the system and developers. I simply employ use cases as another tool in my agile toolbox.

    Cheers, and thanks for listening!

Leave a Reply to Jarno Vähäniitty Cancel reply

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

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

Google photo

You are commenting using your Google 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 )

Connecting to %s