Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

Agile requirements

Freshness Warning
This blog post is over 21 years old. It's possible that the information you read below isn't current and the links no longer work.

The Rational Edge describes how to do effective requirements management and mitigate software risk within an agile development project in Agile Requirements Methods.

The article is written by Dean Leffingwell, one of the authors of the excellent Managing Software Requirements: A Unified Approach.

Leffingwell sets forth some basic principles of managing requirements. Software development teams should only create the documentation that adds value. Creating documentation is a time-consuming and expensive process, so if that documentation doesn’t help the development process then it shouldn’t be created at all.

Teams should choose a methodology that is appropriate to the project. Generally the larger and more distributed the team or the more critical a project is, the greater the need for documentation.

Lefingwell also sets out the requirements framework for three distinct types of projects. One using Extreme Programming, a larger project still using an agile methodology, and a project requiring a more robust methodology.

By understanding that requirements documents are created to manage risk and by recognizing likely sources of project risk, a development team can tailor their requirements methodology to meet the needs of an individual project.

Recently Written

Too Big To Fail (Apr 9)
When a company piles resources on a new product idea, it doesn't have room to fail. That keeps it from succeeding.
Go small (Apr 4)
The strengths of a large organization are the opposite of what makes innovation work. Starting something new requires that you start with a small team.
Start with a Belief (Apr 1)
You can't use data to build products unless you start with a hypothesis.
Mastery doesn’t come from perfect planning (Dec 21)
In a ceramics class, one group focused on a single perfect dish, while another made many with no quality focus. The result? A lesson in the value of practice over perfection.
The Dark Side of Input Metrics (Nov 27)
Using input metrics in the wrong way can cause unexpected behaviors, stifled creativity, and micromanagement.
Reframe How You Think About Users of your Internal Platform (Nov 13)
Changing from "Customers" to "Partners" will give you a better perspective on internal product development.
Measuring Feature success (Oct 17)
You're building features to solve problems. If you don't know what success looks like, how did you decide on that feature at all?
How I use OKRs (Oct 13)
A description of how I use OKRs to guide a team, written so I can send to future teams.


What I'm Reading


Adam Kalsey

+1 916 600 2497


Public Key

© 1999-2024 Adam Kalsey.