Success with Requirements

Volume 2 :: Number 1 :: 2008
ISSN: 1936-3583

Welcome to our Newsletter

Perhaps you are on an agile team, or will soon (or hope to) transition to agile practices. How do you "do" agile requirements when your product is large and complex? Can you strike a balance between gaining upfront understanding of product requirements while honroing the agile imperatives for delivering buisness value and iterative development?

I work with agile teams and most of them are implementing large software products. In this month's eNewsletter, I share how to develop requirements on large agile projects just enough requirements, just in time.

I hope you'll find it useful. As always, I welcome your comments. Please let me know what topics you'd like to see me address in upcoming eNewsletters.

~ ellen

Ellen Gottesdiener,
President and Principal Consultant
EBG Consulting, Inc.
http://www.ebgconsulting.com

In this issue:

Agile Requirements in Context eLearning

eLearning, Blended Classrooms, and Public Offerings

Upcoming Events

Resources of Interest

Archive Issues

Agile Requirements, In Context

As I discussed my August eNewsletter (see the link to the archive, below), there's a lot of hype about the role of requirements in agile projects. Many people think you don't "do" requirements on an agile project. Hogwash. Indeed, agile projects use requirements' but just enough requirements at just the right time.

Agile requirements need to be understood in context of the product, release, and iteration.

Consider iterations, a key attribute of agile projects. How can you usefully define an iteration without developing some requirements? At what point in your project will you realize, retrospectively, that the rework involved in refactoring your architecture outweighs the time it would have taken for you to understand the big picture,something you get when you do requirements right?

I work with clients adopting agile practices. One of the greatest challenges is scaling agile practices when you're building and enhancing large, complex software products. This issue surfaces early in a project, when the team has to decide which slice of the application to build for the first iteration.

In complex products, a good approach is to exploit one of agile's greatest strengths: the imperative to reduce risk and increase learning as soon as possible. By building a small slice of the product and getting feedback on it immediately, teams quickly and inexpensively expose technical unknowns, while customers discover and explore true needs (requirements).

Balancing Business and Technical Value

But just jumping into building a slice the application can be risky in andof itself. How do you know where to start? The customer may believe there is a great need for certain user requirements to be satisfied, and indeed there may be. Some teams discover that, depending on the product, you can't fully satisfy some user requirements until you build a subset of nonfunctional requirements or set up a technical infrastructure.

Another phenomenon on large projects with multiple teams is the discovery, after "sprinting" (e.g., iterating) two or three times, that the different teams need the big picture to better coordinate their work.

The trick is balancing business need with technical feasibility.

An effective solution is to hold a series of interlocking workshops to deliver requirements-driven roadmaps and product plans. These workshops work on three levels: product, release, and iteration. They involve the project community- the technical team and the business customers (product owners). This is illustrated here.

Product Workshop

Start with a product workshop to define your vision, the project scope, and a product roadmap. In this workshop you define which product features you will release over time. This workshop is done once for the product and serves as a guidepost for subsequent releases and iterations.

Identify the vision you have for the product, documenting it in a vision statement, a product "box", or a metaphor. From there, define product scope using scope-level analysis models such as a context diagram, a list of events, conceptual entities, or a list of features in and out of scope.

Then, armed with this high-level understanding of the product, you create a product roadmap that reflects both a wide and a narrow view of the requirements that are needed to satisfy the product vision over time.

To create your product roadmap, group your scope-level requirements into feature categories (e.g., ordering, reporting, performance, etc.). Then analyze their interdependencies and their business value. Many teams do this by writing high level stories (i.e., epics) on cards and arraying them on the wall. Some teams use high-level use cases (i.e., named user goals, each with a one or two sentence description). The team needs to decide which portions of which features will be delivered in each release and determine a release schedule (perhaps two to four months).

Your goal is to gain understanding of the big picture - as a project community. Define the scope at a high level, using analysis models. Build your roadmap in a collaborative fashion, bringing together the product owners (business stakeholders) and the delivery team (technical stakeholders). I like using workshops as the venue for making this happen.

Release Workshops

For each release, create a release plan to define what will be delivered for a release. Each release will implement a subset of features, taking into account both business need and architectural dependency.

Releases tend to last three to six months and incorporate three to six iterations. Any given release plan is based on your understanding of requirements at this early point. You will need to conduct this release planning workshop for each release, roughly every two to four months for large products.

A requirements-driven release plan includes scenarios or stories (or lightweight use cases), a first-cut data model, quality attributes or quality attribute stories, and perhaps personas or actors. To understand dependencies, you can use pre- and post-conditions on events (or scenarios), allowing you to sequence the functionality of your iterations appropriately. Your context diagram should be used to define interfaces that need to be built into a release.

Iteration Workshops

Each iteration starts with an iteration planning workshop in which the team decides what requirements from the requirements backlog to deliver in the iteration - given team capacity, risks, and product development status. The iteration planning session also incorporates feedback from the prior iteration's demo and retrospective.

Your iteration planning workshop includes documentation of user requirements (such as stories or scenarios), quality attribute stories or story "doneness" expressed as quality attributes, integration stories, and any technology or tool-related tasks that need to be completed. Some stories will need to "right-sized" and re-prioritized during the workshop.

After each iteration planning workshop, the team holds one or more informal requirements workshops to develop requirements for the current iteration. These workshops focus only on the requirements for the current iteration. They may be very informal (such as whiteboard or flipchart modeling sessions), or more formal and require pre-planning (such as when multiple product owners or members of other related teams must be present).

Outside the workshop, a business analyst or product owner should start requirements exploration for the next iteration (working one iteration in advance, to jump-start the next iteration planing workshop) while also supporting requirements definition and testing in the current iteration.

Recurring Retrospectives

An essential element of all these workshops are retrospectives. These workshops give you feedback on both the work product and the team process. Remember: you're not doing agile unless you're doing retrospectives! And even if you're not currently using agile approaches, retrospectives are an essential tool for any business and technical professional.

Requirements Matter

Agile projects can't abandon requirements development and management. Agile projects need requirements. A requirements-driven "albeit lightweight" approach to large agile projects saves time and money and accelerates the team's ability to deliver the right product, sooner.

Agile on large, complex products means you develop the necessary level of requirements to meet the needs of the successive level of stakeholders. Each level delivers what is useful to the next level - and not more. In this way, you lighten and tighten requirements develop to fit the rhythm of agile delivery, in context of product, release, and iteration.

~ ellen

Standard citation for this article:
Ellen Gottesdiener, Agile Requirements, in Context, Success with
Requirements, Vol. 2, No. 1(2008).

References:
Ellen Gottesdiener, "Requirements Practices on Agile Projects," Success with Requirements, Vol. 1, No. 8(2007). Archive issue

Thanks to Ferhan Bulca for his helpful comments on an earlier draft.

eLearning, Blended Classroom, and Public Offerings

Take self-paced eLearning, or optionally combine it with our expert instructor-led training for our unique "blended classroom" offering. Discount information for you, a subscriber to Success with Requirements, is provided below.

1. Self-paced eLearning: Roadmap to Success: Foundation for Requirements Development and Management.

This content rich and engaging training includes:

Long-term access (45 days) to the "Roadmap to Success:Foundation for Requirements Development and Management" curriculum

A copy of the industry's "go to" book on requirements: The Software Requirements Memory Jogger

Downloadable templates and printable tips to use on the job for years to come

Click here to learn more or register. Subscribers to Success with Requirements receive special pricing. Use DISCOUNT CODE: RFRTS05.

2. Blended Classroom: Roadmap to Success: Comprehensive. We are offering this unique, blended training publicly in two locations:

March 26-27, 2008: Indianapolis, Indiana

April 16-17, 2008: Orlando, Florida

This unique blended learning experience includes all the items listed above (Roadmap to Success: Foundation for Requirements Development and Management) PLUS:

Two days of instructor-led training in "Analysis Modeling" Course guide for "Analysis Modeling"

Mini-poster of the Requirements Roadmap

Continental breakfast, lunch, snacks for the two-day

Instructor-led training event

Completion certificate

Click here to learn more or register. Subscribers to Success with Requirements receive a 10% discount. Use DISCOUNT CODE: RCRTS05.

Project Management Training
Fellow "Memory Jogger" author, Karen Tate (The Project Management Memory Jogger and The Advanced Project management Memory Jogger has a generous discount on upcoming public offerings of Griffin Tate Group's (GTG) project management training for "Success with Requirements" subscribers:

1. Structuring Successful Negotiations

This course focuses on building these essential skills and outlines their importance to project and program management success or failure. It delves into the key stages of a negotiation: analysis, determining your BATNA, planning the negotiation meeting, the negotiation, and negotiation tactics and strategies.

Upcoming offerings are in:

Atlanta (February 20)

Cincinnati (March 13)

Success with Requirements eNewsletter subscribers offering get a discount with this link.

2. Project Leadership: A Practical Guide to Communication, Influence, and Collaboration.

This workshop helps project leaders and project team members improve their skills in the following areas: communicating within the team and outside of the team, making decisions as a team, avoiding or resolving conflict, understanding and working with diverse thinking and learning styles, providing constructive feedback, and running effective meetings. Attendees will also learn how to obtain the support of project sponsors and management and the commitment of project team members using influencing skills and improved communication.

Upcoming offering is in:

Atlanta (June 25-26)

Success with Requirements eNewsletter subscribers get a discount with this link.

Upcoming Events

1. Ellen Gottesdiener will be delivering a presentation on "Agile Analysis" at the Central Indiana Chapter of the IIBA on February 12, 2008.

2. Ellen will be teaching the instructor-led portion of our new blended classroom (self-paced combined with instructor-led) offering, Roadmap to Success: Comprehensive Foundation and Analysis Modeling in Indianapolis (March 26-27, 2008). See more info above on reader discounts. Register early to reserve your spot, class size is limited!

3. Mary Gorman will be delivering two full-day workshops and a presentation at Business Analyst World/Project World, Toronto (April 14-19, 2008).

4. Ellen will present the instructor-led portion of our blended classroom offering, Roadmap to Success: Comprehensive Foundation and Analysis Modeling in Orlando (April 16-17). See more info above on reader discounts. Register early to reserve your spot!

5. Mary will be presenting two full-day workshops and a presentation at Business Analyst World/Project Summit, Philadelphia, PA (April 28-May 1, 2008).

Resources of Interest

Each month we'll provide a few resources we think are worthwhile. The resources below relate to the topic of the featured article, agile planning and requirements and the role fothe business (product) owner.

I welcome your comments and suggestions for future issues!

Hubert Smits excellent article, "Five Levels of Agile Planning: From Enterprise Product Vision to TeamStand-up", is a must read (note: sign-up to Rally Software's portal to access the paper is necessary).

The essential reason why a product roadmap is needed is discussed in this article by Jacques Murphy, "The Product Roadmap to the Promised Land"

The product roadmap is laid out based on the product vision. Who owns the vision? Jim Shore discusses the vital role the product manager (a.k.a., the product owner in Scrum).

Read a brief summary of how eXteme Programming (XP) (an agile method) employs a release plan.

Visible workspace for product, release and iteration workshops is essential. This article describes how three practitioners (including Ellen Gottesdiener) use walls for collaborative workshops.

Archive Issues

Visit our archive to read our prior issues.

Publication & Reprint Information

I invite you to reprint material from Success with Requirements in other electronic or print publications provided this copyright notice ("Written and edited by Ellen Gottesdiener, copyright EBG Consulting, Inc., [year]. All rights reserved.") and a link to http://www.ebgconsulting.com/ is included in the credits. Please send us copy of the publication that includes our reprint, along with a cover note referencing that it is a reprint.

Success with Requirements is a trademark of EBG Consulting, Inc.