As a software engineer, there are always several areas of activity that require my attention during development. Most of my effort is spent working with the business domain, implementation technology, and the development process itself. I've always been the most interested in implementation technologies. The business domain requires a great deal of my attention though too, just so that I can do my job well and understand the customer. The development process has often received less of my attention simply because there are so few hours in a day. In my new position, though, the development process is the business domain. This is refreshing; it lets me focus on building a vocabulary and understanding of software development that I will continue to apply for the rest of my career.

One step of my process of gaining domain experties is to read a lot of background material. One of the first books on my list is Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise by Dean Leffingwell. This post is a summary of the first two parts of the book.

Leffingwell divides his book into four sections. The first gives an overview over the book and his big picture model. The second section covers requirements at the team level. The third section moves to the multi-team/program level. The final section steps out even further to cover portfolios of products.

Dean begins the book with a summary of development methodologies and describes how we progressed to modern Agile over time. This story begins with the Waterfall model. In this methodology, requirements are fixed at the beginning of the development process. Cost and schedule are also estimated up front and these estimates become fixed. Fixed cost, schedule, and requirements make up the Iron Triangle. One problem with Waterfall is that it tends to fix all three points on the triangle. Fixing these points assumes perfect estimation and problem understanding, which is never the case. A team is left with quality as the only aspect of software they can vary to meet goals.

The author moves on to describe the incremental and iterative approaches that followed and how these led to today's lightweight and adaptive Agile methodologies. He summarizes the most popular methods, Scrum and XP. These methods change the fixed points on the Project Management Triangle. Schedule and resources are fixed, but scope is now varied.

Leffingwell also covers lean software development, another modern software movement. Lean shares many values with those laid out in the Agile Manifesto. Leffingwell has a good post summarizing the philosophies behind Lean. An important aspect of this development style is flow, which he describes in a post on product development flow.

Dean moves on to cover his big picture model, which is the context in which the rest of the book is written. At the lowest level is a team. A team has a backlog of user stories driving their development. Stories are broken down into tasks, which represent a unit of work to do. Software is built in multiple iterations leading to a release - a Potentially Shippable Increment (PSI). These PSI are typically delivered after several iterations, somewhere between 60 to 90 days.

Above teams is his diagram is the program level. The program level uses a backlog as well, except the items in this backlog are features building a product vision. To move off the backlog, features are decomposed into sets of user stories for the team backlogs. The program level also has a roadmap. The roadmap differs from the vision by including dates.

The portfolio sits above the program level in the big picture. This level, too, has a backlog. The portfolio's backlog contains epics. Epics are decomposed into a set of features for the program level. This level is driven by broad investment objectives and themes. Themes have a long lifespan and define the core business value.

I like the parallelism in this big picture. Leffingwell scales up the agile team into two higher level tiers across the business, but keeps the same terminology and structure. Each level's backlog is broken down and feeds into a lower level. Each higher level is more abstract. The diagram shows how to scale up requirements through abstraction.

The next three chapters cover a brief summary of each of the following parts of the book. Leffingwell starts with agile requirements for a team. Teams have a profound relationship with requirements:

"A team exists to define, build and test new functionality."

This functionality is represented by the requirements. The backlog is that set of requirements in the form of user stories, and the backlog is each team's definitive source of work. Each story in the backlog has a four step lifecycle: define, build, test, and accept.

He moves on to discuss agile requirements for the program. At this level, teams are organized around features. Features represent a large amount of work and, as such, teams at this level might only have a few features in a backlog. This level also has to deal with coordinating the larger releases representing the efforts from multiple teams. This level runs on a longer cycle:

"The PSI is to the enterprise what the iterations are to the team..."

The final summary chapter covers agile requirements for the portfolio. This level describes where and why an enterprise invests. Dean lays out four types of investment: existing programs, new programs, future programs, and sunsetting. Another context for the first three investment types is Geoffrey Moore's three horizons outlined in Escape Velocity. This level also includes an architecture runway. The runway addresses large, cross-team issues that might affect most of the teams or code. The runway addresses the issue that not all architecture decisions can be solved by individual teams refactoring and solving technical debt. A personal example of this from my own experience is the decision to do major technology stack upgrade.

The second section of the book dives down into detail at the team level. Much of the material in this section is familiar agile development methodology. Leffingwell dedicates the first section to user stories. This post on user stories hits most of the important points in the chapter. The alliteration "Card, conversation, confirmation" is a great one summarizing the meat of a user story. The author also introduces an acronym covering the important attributes of a user story: INVEST. INVEST stands for independent, negotiable, valuable, estimable, small, and testable.

The author next describes stakeholders and user personas. This is a pretty familiar topic, so I'm simply going to link to a blog post on personas that I like. Leffingwell does caution, though, that a system should only have a couple primary personas. Additional personas should be secondary and not drive development in the same way.

The author moves on to estimating in agile. These concepts, too, are familiar. Estimating in agile often uses a story point. This is a unit-less number that only has meaning in contrast to other stories and only within the scope of a team. This number represents the effort required to complete a story based on knowledge, complexity, volume, and uncertainty. The author touches on a couple ways to build these estimates: planning poker and tabletop relative estimation. In addition to story points, the author introduces ideal developer days - a unit representing exactly what you would expect. The author suggests a hybrid of the two approaches, where one story point is equated to one day of development. Each team's velocity is set to eight times the team size for a two week sprint.

Next, Leffingwell describes a team's iterations. Each iteration consists of three parts: an initial plan, the execution, and finally a review and retrospective. In execution we're finally to the meat of things: building software. Each story is broken into tasks. The author introduces another acronym to help write good tasks, SMART. SMART stands for specific, measurable, achievable, relevant, and time-boxed. Much of this chapter touches on a larger theme of the book (and Agile): visibility. Dean describes how Agile makes team progress visible.

Lean and Kanban make another appearance in this chapter, in reference to managing the backlog. The larger, product backlog (not the iteration's) is still a work queue, and must be carefully managed. A long work queue is dangerous. This is another area where I have relevant personal experience. A project backlog with too many items is a constant drain. Sifting through it becomes expensive. At times, I also found it demoralizing constantly seeing a list of things I knew would never actually get done. Kanban has explicit limits on work in progress, which is great. The backlog needs to be finite too.

Dean covers acceptance tests next. These tests are critical because:

"... it is the details of these tests that define the final, agreed-to behavior of the system"

When discussing user stories, the author describes that they should be lightweight and disposable. When stories are discarded, though, the system's behavior must be documented somewhere else. Acceptance tests fill this role. They represent how the system should behave and, ideally, should be automated. With this type of framework, designing and then building the right tests assures the system will behave as desired.

After tests, the author discusses the role of the product owner. Leffingwell makes several key points about a product owner, one of which is that they must be a member of the team. The product owner has several responsibilities. Product owners:

• manage and prioritizes the backlog
• develop user stories
• help to plan an iteration
• play a role in the larger picture by helping to plan the release/PSI

The final element of part two is a collection of other tools for gathering requirements. On such tool is the requirement workshop. This is day or two long session with all the key stakeholders. Another tool that groups key stakeholders is a product council. This council helps to make key prioritization decisions. Other tools include brainstorming, interviews and questionnaires, user experience mock-ups, competitive analysis, and customer facing change request systems.

The requirements define the ultimate software that we build. Though a truism, I still think it's worth mentioning because this implies that the right requirements are a pre-requisite to any successful software. Leffingwell's approach has a good perspective by focusing on requirements and managing requirements at enterprise scale.