Channels ▼
RSS

Design

Dr. Dobb's Agile Modeling Newsletter


In This Issue:

  • Rethinking Requirements Management
  • Book Review: Implementing Lean Software Development
  • Hot Links

Rethinking Requirements Management

One of the most visible differences between agile software development and traditional software development is the way that we approach requirements. By now you're probably sick and tired of hearing about how agilists embrace change, so it's time to move past this concept in this newsletter. What I want to explore is three nuances of agile requirements management which we don't hear about as often:

  • The relationship between defects and requirements.
  • The need to put more than just requirements on your stack.
  • Questioning the concept of requirements entirely.

In my January 2007 "Agile Edge" column entitled Agile Testing Strategies I described how many agile teams choose to have an independent test team which performs investigative testing throughout the lifecycle. When this independent team finds a potential bug in the software they write up a "defect story", the agile equivalent of a defect report, and give it to the development team. Agilists treat defect stories like any other type of requirement: They are prioritized, estimated, and put on the stack.

Wait a minute! A defect story is a type of requirement? You bet. A defect story describes either broken or missing behavior: If it describes broken behavior, then the requirement is effectively "Rework X so that Y happens". If it describes missing behavior, then clearly it's a potential requirement. When you think about it, a "requirement" should similarly be considered a defect because it describes missing behavior. For example, the Eclipse project, the largest agile development project currently underway, maintains its requirements in Bugzilla, an open source defect tracking tool. I've heard of agile RUP teams using ClearQuest, a commercial defect tracking tool, in a similar manner.

The only time that the "a defect is a requirement" philosophy can get you in trouble is with a fixed-price project. With fixed-price projects you want to ensure that you are paid to implement new functionality that wasn't originally specified. In these situations defect stories which describe missing functionality must be put through a change management process where the business stakeholders determine whether they wish to pay for the new functionality.

A second issue which agilists don't talk about often is the need to put more than just requirements on our "requirements stack". Or, perhaps another way to look at it is that we have several stacks to manage, not just a requirements stack. Either way, our current work queue needs to reflect the fact that implementing requirements isn't the only thing that we do during an iteration. People go on vacation or on training courses. They also do non-project related work, such as reviews of work performed by other teams or HR-related activities such as staff reviews. All of these things are important and must be planned for, along with implementing new functionality.

The Open Unified Process (OpenUP) takes an interesting approach to managing our work. OpenUP teams maintain a single "work items list" upon which we place prioritized requirements as well as non-requirement activities such as vacations, external reviews, and so on. Where Scrum has two stacks, the Sprint backlog which is where the requirements for the current iteration are managed and the Product backlog where all other requirements are maintained, OpenUP has just the one stack of work items. OpenUP's work items list is effectively a more robust combination of Scrum's Sprint Backlog and Product Backlog.

The third idea is that we should consider rethinking the concept of requirements completely. Is something really a requirement if it evolves over time? Is something really a requirement if it gets deprioritized and as a result never gets implemented? Is something really a requirement if it gets reorganized into smaller pieces and then only a subset of the pieces is implemented?

Philippe Kruchten and Steve Adolph, both of the University of British Columbia, introduced me to this concept about a year ago during our work on the OpenUP. Their philosophy is that it really isn't requirements which we are gathering, or eliciting, or whatever verb you prefer, but instead it is the stakeholder's intent which we are trying to understand. We know that our stakeholders aren't very good at defining their "requirements", yet many software development processes still aim to define requirements in detail and worse yet strive to baseline them early in the lifecycle. Our real goal should be to understand our stakeholder's goals and desires and then build software which reflects those intents.

My hope is that this newsletter has made you rethink the way that you view requirements management. I suspect that most organizations will see the benefits to be derived from treating defects as a type of requirement. I also think that most agile teams will benefit from the "work items stack" approach taken by OpenUP. Finally, although I truly believe that intent is a far better concept than requirements, that in the term "requirement" is too embedded in the IT lexicon for us to ever evolve away from it. Time will tell.

Book Review: Implementing Lean Software Development

As its title suggests, Implementing Lean Software Development is a follow up to Rick Brandon and Tom and Mary Poppendieck's first book, Lean Software Development, where they show how to apply the lean principles in practice. The principles have evolved a bit since their first book, they are now: Eliminate Waste, Build Quality In, Create Knowledge, Defer Commitment, Deliver Fast, Respect People, and Optimize the Whole.

Although the book is chock full of valuable wisdom, I believe that the primary skill that you will gain from this book is how to recognize, and then address, wastage within your software processes. Waste is caused by building extra features into a system (you're doing extra work); unnecessary churn, resulting from specifying detailed requirements and design too early or testing too late; and having unnecessary boundaries between groups or even individuals over which work must cross, boundaries where defects are often injected and loss of information occurs.

I believe that this is one of the few "must read" books for any software professional. If you're an agilist it will explain many of the concepts which you sense to be true but don't know why. If you're a traditionalist then it will explain why many of the things that you sense are wrong about your software process are truly inefficient.

Implementing Lean Software Development: From Concept to Cash by Rick Brandon and Mary and Tom Poppendieck --SWA

Hot Links

The Agile Alliance is the best starting point for anyone interested in learning more about agile software development.

Inclusive modeling tools and techniques which support active stakeholder participation in intent/requirements-oriented modeling are described at www.agilemodeling.com/essays/inclusiveModels.htm.

Agile requirements change management is described in detail at www.agilemodeling.com/essays/changeManagement.htm.

The www.eclipse.org/projects/dev_process/.

You can learn more about Scrum at the Implementing Scrum site.

The Agile Models Distilled page provides links to overviews of a wide variety of models.

The principles of Agile Modeling v2 are described at www.agilemodeling.com/principles.htm.

The practices of Agile Modeling v2 are described at www.agilemodeling.com/practices.htm.

Check out the Agile Modeling mailing list at www.agilemodeling.com/feedback.htm.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video