Agile software requirements lean requirements practices

Use notes for ideation of requirements and models. Elicit requirements from Stakeholders using our conversation tool. Publish formatted requirements with their associated tasks in table format.

Publish formatted test cases with their associated test steps in table format. Export Diagrams, Matrices, and models with their associated requirements. Type out static reports and inject queries to provide dynamic content. Build question lists which help teams elicit and author requirements. See our features in a technical walkthough with product experts. Streamline Approvals Significant reduction in approval delays. Reduce Rework fold reduction in development rework. Request a Demo!

Schedule a demo with one of our trained product experts. Receive a personalized demo that mimics your team's process Engage our experts on topics such as workflow or best practices.

Book Now! By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy. Close Privacy Overview This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website.

Our objective must be to help the enterprise achieve the full benefits of lean and agile development. Even the language is different and seemingly odd user stories, sprints, velocity, story points, epics, backlog? So, there will likely be many challenges. Even for the fully committed, it can take six months to a year to introduce and implement the basic practices and even more time to achieve the multiples of productivity and quality results that pay the ultimate dividends in customer satisfaction, revenue, or market share.

To achieve these benefits, we must change many things, including virtually all of our former requirements management practices. So, we have a dilemma—how do we practice this new high-wire act without a safety net, when the safety net itself is a big part of the problem? Fortunately, we are now at the point in time where a number of organizations have made the transition before us and some common patterns for lean and agile software process success have started to emerge.

Eventually, and with help from others, we arrived at something that worked reasonably well for its purpose. However, from an overview perspective, the following highlights emerge. In the smallest enterprise, there may be only a few such teams. In larger enterprises, groups, or pods, of agile teams work together to support building up larger functionality into complete products, features, architectural components, subsystems, and so on.

The ART is a standard cadence of timeboxed iterations and milestones that are date- and quality-fixed, but scope is variable no iron triangle. The ART produces releases or potentially shippable increments PSIs at frequent, typically fixed, to day time boundaries.

Investment themes drive the portfolio vision, which will be expressed in as a series of larger, epic-scale initiatives, which will be allocated to various release trains over time. Often the testers are logically part of the QA organization but are physically assigned and dedicated to an agile team. In this matrix fashion, their primary allegiance is to the team, but as members of the QA organization, they can leverage other QA teammates and managers for skills development, automation expertise, and any specialty testing capabilities that may be necessary at the system level.

In any case, it must be clear that the agile team itself is responsible for the quality of their work product and that responsibility cannot be delegated or abrogated! Teams are typically organized to deliver software features or components. Most enterprises will have a mix of both types—some component teams focused on shared infrastructure, subsystems, and persistent, service-oriented architectural components and some feature teams focused on vertical, user-facing, value-delivery initiatives.

Agile teams are self-organizing and reorganize when necessary based on the work in the program backlog. In Scrum, the product owner is responsible for determining and prioritizing user requirements and maintaining the product backlog.

In support of Agile Manifesto principle 4—Business people and developers must work together daily throughout the project—the product owner is ideally co-located with the team and participates daily with the team and its activities. As their skills develop, many of these Agile Masters become future leaders by illustrating their ability to deliver user value and by driving continuously improving agile practices. Developers and Testers Developers and Testers Four to Six The rest of the core team includes the developers and testers who write and test the code.

Since this is an agile team, the team size is typically limited to about three to four developers plus one to two testers, who are ideally co-located and work together to define, build, test, and deliver stories into the code baseline. Iterations In agile development, new functionality is built in short timeboxed events called iterations sprints in Scrum. In larger enterprises, agile teams typically adopt a 4.

As the teams master the agile process, the role becomes less critical. Some very agile teams, even those who have adopted Scrum, no longer have a Scrum Master per se. Everybody knows the rules, and they are self-enforced. Each iteration represents a valuable increment of new functionality, accomplished via a constantly repeating standard pattern: plan the iteration, build and test stories, demonstrate the new functionality to stakeholders, inspect and adapt, repeat.

In the Big Picture, the iteration lengths for all teams are the same since that is the simplest organizational and management model. Although there is no mandated length, most have converged on a recommended length of two weeks.

This pattern is arbitrary, and there is no fixed rule for how many times a team iterates prior to a potentially shippable increment PSI. Many teams apply this model with four to five development iterations and one hardening iteration per release, creating a cadence of a potentially shippable increment about every 90 days.

This is a fairly natural production rhythm that corresponds to a reasonable external release frequency for customers, and it also provides a nice quarterly planning cadence for the enterprise itself. In any case, the length and number of iterations per release increment, and the decision as to when to actually release an increment, are left to the judgment of the enterprise.

As commonly taught, the user story often takes a standard user-voice form of the following: As a , I can so that. Identifying, maintaining, prioritizing, scheduling, elaborating, implementing, testing, and accepting user stories is the primary requirements management process at work in the agile enterprise.

Therefore, we will spend much of the rest of this book further describing processes and practices around user stories. Tasks For more detailed tracking of the activities involved in delivering stories, teams typically decompose stories into tasks that must be accomplished by individual team members in order to complete the story.

Indeed, some agile training uses the task object as the basic estimating and tracking metaphor. However, the iteration tracking focus should be at the story level, because this keeps the team focused on business value, rather than individual tasks. Tasks provide a micro—work breakdown structure that teams can use or not to facilitate coordinating, estimating, tracking status, and assigning individual responsibilities to help assure completion of the stories—and thereby—the iteration.

Release or PSI Release Planning Although the goal of every iteration is to produce a shippable increment of software, teams Release Planning Release Theme and Objectives especially larger-scale enterprise teams find System Team Feature 1 that it may simply not be practical or appropriate to ship an increment at each iteration boundArch 1 ary.

For example, during the course of a series of Feature 2 iterations, the team may accumulate some techNonfunctional Requirements nical debt that needs to be addressed before shipment.

Technical debt may include things such as defects to be resolved, minor code refactoring, deferred system-wide testing for performance, reliability, or standards compliance, or finalization of user documentation. Hardening iterations indicated by an iteration with an empty backlog are included in the Big Picture to provide the time necessary for these additional activities. Team Backlog Program Backlog Releases and Potentially Shippable Increments Moreover, there are legitimate business reasons why not every increment should be shipped to the customer.

The Vision answers the big questions for the system, application, or product, including the following. What problem does this particular solution solve? What features and benefits does it provide?

For whom does it provide it? What performance, reliability, and so on, does it deliver? What platforms, standards, applications, and so on, will it support? The Primary Content of the Vision Is a Set of Features A Vision may be maintained in a document, in a backlog repository, or even in a simple briefing or presentation form. But no matter the form, the prime content of the Vision document is a prioritized set of features intended to deliver benefits to the users.

Nonfunctional Requirements In addition, the Vision must also contain the various nonfunctional requirements, such as reliability, accuracy, performance, quality, compatibility standards, and so on, that are necessary for the system to meet its objectives. The program backlog may or may not also contain Wow! However, any estimates at this scale are coarse-grained and imprecise, which prevents any temptation to over-invest in inventory of tooearly feature elaboration and estimation.

Release Planning In accordance with emerging agile enterprise practices, each release increment timebox has a kickoff release planning session that the enterprise uses to set the company context and to align the teams to common business objectives for the release. The input to the release planning session is the current Vision, along with a set of objectives and a desired, prioritized feature set for the upcoming release. By breaking the features into stories and applying the agreed-to iteration cadence and knowledge of their velocity, the teams plan the release, typically in a group setting.

During this process, the teams work out their interdependencies and design the release by laying stories into the iterations available within the PSI timebox. In addition to the plan itself, another primary result of this process is a commitment to a set of release objectives, along with a prioritized feature set.

Thereafter, the teams endeavor to meet their commitment by satisfying the primary objectives of the release, even if it turns out that not every feature makes the deadline. The Roadmap consists of a series of planned release dates, each of which has a theme, a set of objectives, and a prioritized feature set.

Releases beyond the next one are not committed, and their scope is fuzzy at best. However, it is subject to change—as development facts, business priorities, and customers need change—and therefore release plans beyond the next release should not generally be used to create any external commitments. Vision Product Management Program Backlog Product Management In agile, there can be a challenge with the apparently overlapping responsibilities of the product manager and the product owner.

For example, in Scrum, the product owner is responsible for the following: representing the interests of everyone with a stake in the resulting project. However, in the larger software enterprise, the set of responsibilities imbued in the Scrum product owner is more typically a much broader set of responsibilities shared between team and technology-based product owners and market or program-based product managers, who carry out their traditional responsibilities of both defining the product and presenting the solution to the marketplace.

However, we also note that the title of the person who plays this role may vary by industry segment, as shown in Table 2—1. At the top of the Big Picture, we find the portfolio management function, which includes those individuals, teams, and organizations dedicated to managing the investments of the enterprise in accordance with the enterprise business strategy. We also find two new artifact types, investment themes and epics, which together create the portfolio vision.

Investment Themes Portfolio Management Portfolio Backlog Investment Themes A set of investment themes establishes the relative investment objectives for the enterprise or business unit. These themes drive the vision for all programs, and new epics are derived from these themes.

The derivation of these decisions is the responsibility of the portfolio managers, either line-of-business owners, product councils, or others who have fiduciary responsibilities to their stakeholders.

The result of the decision process is a set of themes—key product value propositions that provide marketplace differentiation and competitive advantage. Themes have a much longer life span than epics, and a set of themes may be largely unchanged for up to a year or more.

Epics and the Portfolio Backlog Epics represent the highest-level expression of a customer need. Epics are development initiatives that are intended to deliver the value of an investment theme and are identified, prioritized, estimated, and maintained in the portfolio backlog.

Prior to release planning, epics are decomposed into specific features, which in turn are converted into more detailed stories for implementation. With epics, clearly, the objective is strategic intent, not specificity. In other words, the epic need only be described in detail sufficient to initiate a further discussion about what types of features an epic implies.

So, any effective treatment of agile requirements must address the topic of architecture as well. Architectural Runway Epic 3 Therefore, system architecture is a first-class citizen of the Big Picture and is a routine portfolio investment consideration for the agile enterprise. For agile teams, the model uses the minimum number of artifacts, roles, and practices that are necessary for a team to be effective.

However, the model expands as needed to the Program and Portfolio levels, in each case providing the leanest possible approach to managing software requirements, even as teams of teams build larger and larger systems of systems.

Your loyalty is to them. Why the Discussion on Teams? As we described in the previous chapters, the nature of agile development is so fundamentally different from that of traditional models that, by necessity, we must rethink many of the basic practices of software development.

More importantly, in agile, the organization of the requirements and the organization of the team itself are not independent things. Rather, the teams organize around the requirements so as to optimize the efficiency of defining, building, and testing code that delivers value to the end users. The entire team is integrally involved in defining requirements, optimizing requirements and design trade-offs, implementing them, testing them, integrating them into a new baseline, and then seeing to it that they get delivered to the customers.

That is the sole purpose of the team. The basic unit of work for the team is the user story the topic of Chapter 6. Each story has a short, incredibly intense development life cycle, ideally followed by long-term residence in a software baseline that delivers user value for years to come. Pictorially, Figure 3—2 shows the life cycle of a story.

In essence, each story operates in the same pattern: Define the story, write the code and the test, and run the test against the code. In so doing, we use the sequence as a verb to illustrate the fact that the process is concurrent, collaborative, and atomic. However, even an atom has its constituent parts, and ours are as follows.

We use the word define to communicate that this function is a combination of both requirements and design. They are inseparable; neither has any meaning without the other.

Story understanding evolves during the coding process. Of course, this process happens every day; it happens in real time, and it happens multiple times a day for each story in the iteration!

How could such a process work in a traditional environment where a product owner or manager may not exist or has been be called away on another mission? How could it work if the test resources are not dedicated and available at the same time that the code is written? Clearly, we are going to have refactor our organization to achieve this agile efficiency.

We are going to have to organize around the requirements stream and build teams that have the full capability to define, build, test, and accept stories into the baseline—every day. Instead, we are likely to be organized in functional silos, as illustrated in Figure 3—3. Developers sit with, and communicate with, other developers. Product management, business analysts, and program managers are co-located with each other and often report to different departments entirely. For the larger organizations, architects may work together so as to help induce common architectures across business units, and so on, but may have little affinity or association with the development teams themselves.

Testers probably report to—and are co-located with—a separate QA organization, rather than development. In agile, we must redefine what makes a team a team and eliminate the silos that separate the functions, as Figure 3—4 illustrates. Product Owner Since the product owner is primarily responsible for defining and prioritizing requirements, it is clear why it is such a critical role in the agile project team. Chapter 11 is devoted to this topic. Although not every team Wow! This role actively addresses these issues so that the team can remain focused on achieving the objectives of the iteration.

Developers Developers write the code for the story. In so doing, they may work in a pairprogramming model with another developer, they may be paired with a tester, or they may operate more independently and have interfaces to multiple testers and other developers. They become part of the team just as soon as new code starts to be laid down, and they continue with the team throughout the release process.

Their cycle is the same as the development cycle. Every new story that reaches an iteration boundary is subject to immediate review and analysis for acceptance testability. In these cases, the local architecture that of the component, service, or feature that the team is accountable for is most often determined by the local teams in a collaborative model.

At the system level, however, architecture is often coordinated among system architects and business analysts who are responsible for determining the overall structure components and services of the system, as well as the system-level use cases and performance criteria that are to be imposed on the system as a whole. For this reason, it is likely that the agile team has a key interface to one or more architects who may live outside the team. Some of these QA personnel will live outside the team, while others primarily testers will have likely been dispatched to live with the product team.

There, they work daily with developers to test new code and thereby help assure new code quality on a real-time basis. Agile Manifesto principle 11—The best architectures, requirements, and designs emerge from self-organizing teams. Moreover, that subset must be quintessentially agile so that the artifacts described are consistent with most agile training as well as common practice. Backlog The term backlog was first introduced by Scrum, where it was described as a product backlog.

However, in our enterprise model, product can be a pretty nebulous thing because various teams may be working at various levels, so there are multiple types of backlogs in the Big Picture. Therefore, our use of the term backlog is more generalized than in Scrum. This backlog is the one and only definitive source of work for the team. It holds all the work primarily user stories that needs to be done.

It is local to them and is managed by them. It is their repository for all identified work items, and the contents are typically of little concern to others in the enterprise. They manage it, tool it, and put things in and out of it as it suits their needs in order to meet their iteration objectives.

Stories Stories and the team backlog Wow! From a model perspective, a story is a kind of backlog item, as Figure 3—7 illustrates. To make the user story explicit, we need to extend the model a little, as shown in Figure 3—8.

Many Scrum teams call these backlogs because they are items in the product backlog. Strictly speaking, work items is probably a better term than story or backlogs, but we are trying to follow the most common usage as well as encouraging the use of the user story format.

The triangle indicator connecting the 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. Other work items include things such as refactors, defects, support and maintenance, and tooling and infrastructure work. They also help the team better estimate the time it will take to actually deliver the user stories. User Story Basics User stories are the agile replacement for most of what has been traditionally expressed as software requirements statements or use cases in RUP and UML , and they are the workhorses of agile development.

Developed initially within the constructs of XP, they are now endemic to agile development in general and are taught in most Scrum classes as well. As commonly taught, the user story takes a standard user voice form: As a , I can so that. Tasks To assure that the teams really understand the work to be done and to assure that they can meet their commitments, many agile teams take a very detailed approach to estimating and coordinating the individual work activities necessary to complete a story.

Story Figure 3—9 Implemented by 0,1 Tasks are the lowest-granularity thing in the model and represent activities that must be performed by specific team members to accomplish the story. In our context: A task is a small unit of work that is necessary for the completion of a story.

Tasks have an owner the person who has taken responsibility for the task and are estimated in hours typically four to eight. The burndown completion of task hours represents one form of iteration status. However, for flexibility, the model also supports stand-alone tasks and tasks that support other team objectives. He used the neat alliteration card, conversation, and confirmation4 to describe the three elements of a user story.

In our model, we represent the confirmation function as a type of acceptance test, one that confirms the story has been implemented correctly.

In any case, the model is explicit in its insistence on the relationship between the story and the story acceptance test as follows. A story cannot be considered complete until it has passed the acceptance test s. Acceptance tests are functional tests that verify that the system implements the story as intended. To avoid creating a large volume of manual tests, which would quickly limit the velocity of the team, story acceptance tests are automated wherever possible. Story 1 Done when passes Unit tests are used to confirm that the lowest-level module of an application a class or method in object-oriented programming; a function or procedure in procedural programming works as intended.

Unit tests are written by the developer to test that the code executes the logic of the subject module. In test-driven development TDD , the test is written before the code. In any case, the test should be written, passed, and built into an automated testing framework before a story can be considered done. Mature agile teams provide comprehensive practices for unit testing and automated functional story acceptance testing. Also, for those in the process of tooling their agile project, implementing this meta-model can provide inherent traceability of story-to-test, without any overhead on the part of the team.

Real Quality in Real Time The combination of creating a lightweight story description, having a conversation about the story, elaborating the story into functional tests, augmenting the acceptance of the story with unit tests, and then automating testing is how agile teams achieve high quality in the course of each iteration.

In this way: Quality is built in, one story at a time. Continued assurance of quality is achieved by continuous and automated execution of the aggregated functional and unit tests. Story 1 We also described a set of requirements artifacts and relationships, including the user story, that are optimized to support the fast delivery of valuable requirements to the software baseline for release to the customers.

Backlog Item Is one of Story Implemented by 0,1 As illustrated in Figure 4—1, at the next higher Program level, we see an organizational, process, and requirements model that provides mechanisms to harness some number of agile teams to a larger enterprise purpose—the delivery of an entire product, system, or application suite to the customers.

At the Team level, teams are empowered and are largely self-organizing and selfmanaging. They have control of their local destiny and can define, build, and test their feature or component. In accordance with the principles of the Agile Manifesto, that is the optimum mechanism for incentivizing and motivating a team to produce the best possible results.

The objectives at this level include the following. Quality management: Assuring that the aggregate results the system of the teams are routinely integrated; that performance, security, reliability requirements; and that any imposed external standards are met.

Deployment: As the teams are unlikely to have the ability, purview, or authority to actually deploy systems to end users, this critical activity must be managed at the Program level. For the smaller enterprise, this is usually no issue at all; they will organize naturally around the few products or applications that reflect the mission. The silos that tend to separate development, product management, and test in the larger enterprise do not exist ideally!

The teams are probably already co-located, rather than being distributed across disparate geographies. Creating an agile team in this context is mostly a matter of deciding what roles the individuals will play and rolling out some standard training. At scale, however, like most other things agile, the problem is different, and the challenge is to understand who works on what and where.

Do we organize around features, components, product lines, services, or what? Although there is no easy answer to this question, the question must be explored because so many agile practices—how many backlogs there are and who manages them, how the vision and features are communicated to groups of teams, and how the teams coordinate their activities to produce a larger solution—must be reflected in that decision.

Component Teams In Scaling Software Agility [Leffingwell ], we described a typical organizational model whereby many of the agile teams are organized around the architecture of a larger-scale system. There, they leverage their technical skills and interest and focus on building robust components, making them as reliable and extensible as possible, leveraging common technologies and usage models, and facilitating reuse. However, we also noted the following: We use the word component as an organizing and labeling metaphor.

Other agile methods. In any case, in a component-based approach, the development of a new feature is implemented by the affected component teams, as Figure 4—2 illustrates.

Component teams minimize multiplexing across features by implementing them in series, rather than parallel. Some advantages are obvious, because each team is able to aggregate the needs of multiple features into the architecture for their component and can focus on building the best-possible, long-lived component or service for their layer.

This approach may be reflective of an architecture-centric bias when building these largest-of-all-known software systems. Agile software requirements : lean requirements practices for teams, programs, and the enterprise. Responsibility Dean Leffingwell. Imprint Upper Saddle River, N. Physical description 1 online resource xxxv, pages : illustrations Series Agile software development series. Online Available online. Safari Books Online Full view.

Report a connection problem. More options. Find it at other libraries via WorldCat Limited preview. This book serves as a good starting point for learning. The narrative balances software engineering theory with pragmatic implementation aspects in an easy-to-understand manner. It is a book that demands to be read in a single sitting. Much more than mere guidelines for creating requirements, building teams, and managing projects, this reference work belongs on the bookshelf of anyone and everyone involved with not only agile processes but software development in general.

We have practiced the multi-team release planning and the enterprise-level architecture work with kanban and achieved instant success in our organization. Combining the principles of the product development flow with the current large-scale agile and lean software development is a really novel concept. Well worth reading and trying out the ideas here. The ART concept is a very powerful tool in planning and managing large software programs and helps to identify and solve potential organizational roadblocks—early.

This product is part of the following series. Click on a series title to see the full list of products in the series.

Pearson offers affordable and accessible purchase options to meet the needs of your students. Connect with us to learn more.