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).

The Big Picture, Highlighting the Requirements Model

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

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

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.