A Lean, Scalable Requirements Information Model for the Agile Enterprise

For those of you who have been following the Big Picture series, you may have noted that one element of the picture is the “requirements information model” that flows down the right side. This element of the model describes agile terms for expressing system behaviors at various levels of abstraction. (See below).

Big Picture with requirements model highlighted

The Big Picture, Highlighting the Requirements Model

In summary form, the model implies the following requirements-related elements and relationships as illustrated below.

requirements-hierarchy

For Big Picture purposes, this is an adequate explanation which helps the enterprise to understand the new labels for “requirement like things” in enterprise agile methods and the way teams use these new things to describe intended system behavior.

However, while the Big Picture supports “hand waving” descriptions of this complex problem, it does not define the exact nature of each element nor the critical relationships between them. For this purpose, my colleague, Juha-Markus Aalto, Director of Operational Development for Nokia S60 Software Unit, and I have been working on a semantic meta-model for agile enterprise requirements information management. The model also serves as the technical underpinnings for the requirements elements of the Big Picture. The need for the more definitive model is driven by two factors:

  1. The need for clear definition of each artifact type, so teams can be coached as how to use the appropriate element (ex: feature, user story, task) at the appropriate time
  2. The need to make explicit the relationships amongst the elements of the model (user stories, acceptance tests, features, etc.) to support tooling automation, which will provide enterprise- level support for status reporting and portfolio estimating and planning.

Last week, Juha-Markus presented this model at Object Days at the Tampere, Finland, University of Technology. His full presentation can be found here.

Lessons Learned at (truly) Enterprise Scale Agile Adoption

The purpose of Juha-Markus presentation was not the model itself; rather it was to describe how this model supports the enterprise level agile practices being deployed in the development of Nokia’s S60 Software Platform and Applications. Nokia’s S60 Platform is a software platform for mobile phones that is currently amongst the leading smart phone platforms in the world. The Platform is built by an extensive network of software teams who are applying Scrum to increase the productivity and quality of their local efforts. S60 in turn, is built on top of the Symbian OS, further coupling the efforts of the Nokia development teams to the many software practitioners of this critical supplier. Nokia S60 teams’ experiences in scaling agile across a large number of intensively collaborative software teams represents some of the most advanced agile thinking and practices, at the greatest scale, of any that I am aware of.

These experiences serve as an excellent object lesson for others in (really) Scaling Software Agility. For more on this topic, I refer you to Juha-Markus’ presentation which will provide a fuller understanding of some of the challenges the S60 teams are addressing with their new agile model.

The Requirements Information Model

The purpose of this post, however, is to introduce the requirements information model that we have been collaborating on. The most basic form of this model (more in future posts), as represented in UML form, is shown below.

A Lean, Scalable Requirements Information Model

A Lean, Scalable Requirements Information Model

When compared to the Big Picture, it’s obvious that the Big Picture graphic is an oversimplification of the reality of large scale, agile system development. While the elements of Epic, Feature, Story, Task and Backlog are described in the Big Picture and elaborated in supportive posts, the elements of Strategic Product Theme and Acceptance Test have not. These are described below:

  • Strategic Product Theme – this information model adds this, new and highest level element to the information hierarchy. Themes provide a well-defined set of core value propositions that in turn, drive portfolio investment. They define the key strengths of the enterprise, deliver on strategic initiatives and solutions, and drive long-term competitiveness. Themes, in turn cause the creation of Epics, Features, and Stories that deliver on the themes value proposition. (In the Big Picture, Themes can be considered to be the various “slices” in the portfolio management pie chart at the upper left)
  • Acceptance Test – moving all the way to the bottom of the stack, the model also highlights the critical role of the acceptance test in agile development. In turn, this encapsulates two key agile quality principles: 1) there is always at least one acceptance test for every story (in agile, all code is tested code) and b) a Story cannot be considered “done” until it passes the test.

Lastly, the Non-Functional Requirement is a primary element in this model, which reflects the role these special requirements play in the development of enterprise class systems. (These were called out as auxiliary elements of the “Vision + in the Big Picture.)

Summary

That summarizes the primary elements of the lean, scalable, requirements information model. To the new or smaller team Agilist, this model may seem relatively complex and perhaps not very agile, or at least not “the simplest thing that can possibly work”. However, experience has shown that thinking about the solution space in these varying levels of abstraction is in fact, a simplification of the problem at enterprise scale and encourages agile thinking throughout the organizational hierarchy. I’ll describe why in an upcoming post.

4 thoughts on “A Lean, Scalable Requirements Information Model for the Agile Enterprise

  1. Dean – this is almost identical to what we are doing (main difference is terminology). What we ended doing at theme level might be of interest to you guys…
    * The tie between epic and them has an inherent priority as well
    * One theme may deem Epic 777 as a MUST to successfully reach the end goal of the them
    * Another theme may only deem Epic 777 as a SHOULD and therefore can be successful without the epic being complete
    * Themes have no correlation to a release (only through the indirect tie to a feature)

    Above allows PM to evaluate priority across themes while also tracking when a given theme is considered ready for market. For example, if two strategic themes declare Epic 777 as top priority, it may make sense to tackle it faster

  2. One more thought… We also declare acceptance criteria at the feature level for the purposes of release level commitments. This is very useful in a culture where autonomy is an issue. By declaring acceptance criteria at the feature level, you proclaim accountability as meeting the “spirit of the epic”. This in turn enables the teams to modify their stories as the PO sees fit so long as the spirit of the epic isn’t compromised.

    During the 2-3 day planning session, teams commit at the epic level. Subsequently during each iteration planning session, teams commit at the story level. If a single team fails to deliver a story within an iteration, it may not be gloom and doom if the spirit of the epic can still be delivered as originally committed.

    This pattern works great when you are trying to play nice with downstream or project management organizations. You teach these groups to become knowledge about the state of the epic and NOT the state of the story. This gives the teams the freedom to truly own something without having to deal with major politics!

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