25 July 2011

Whither Requirements?

We accomplish what we understand. If we are to accomplish something together, we need to understand it together.
Signature from Ron Jeffries e-mail, circa 2005.

A common issue I've encountered with teams starting to use an Agile approach such as Scrum is that they feel they must abandon all existing methods of requirements gathering and start writing nothing but User Stories.

Requirements for a system can be expressed in a multitude of ways, including but not limited to:
  • Traditional "the system shall" type of system requirements
  • Use Cases
  • User Stories
  • People sitting beside each other discussing what needs to be done
These approaches have some significant differences.  Traditional requirements tend to focus on very specific system functionality without a direct view to the ultimate goals of the people who will be using the system.  Use Cases can also have the same problem if they focus on the "how" as opposed to the "what" of a system, although they do represent an improvement.  They also tend towards verbosity with early expression of detail that can lock in specific implementations.  User Stories explicitly focus on the outcomes from a customer value perspective, and intentionally avoid details until they are required.  Sitting with the person or people for whom you are building a system and just talking and showing the work as it progresses avoids all confusion about the work and the need for any formal documentation.

In each of these cases, it's quite possible to change each point from a weakness to a strength and vice versa!  When you get right down to it, all of these forms of requirements and the process of using them have a single underlying goal.

That goal is the achievement of a SHARED UNDERSTANDING of the work to be done.

As Ron's e-mail signature above suggests, it doesn't matter if you use smoke signals, crystal balls or Vulcan mind melds as long as everyone has the same shared understanding of what must be done!  How you achieve that understanding is up to you, although a collaborative approach is almost always the easiest way to get there.  The closer together the people who need the system and those who implement it work, the higher the probability that a shared understanding will occur.  The more frequent the opportunities for feedback, the higher the probability of a shared understanding.  The more you can defer the expression of details in the requirements until they are really needed, the higher the probability.

So, the form in which the requirements are recorded is a secondary consideration to achieving the shared understanding.  You need to be cognizant, though, of the inherent strengths and weaknesses of each approach.  An unrecorded discussion between two people may be the most efficient and lightweight approach, but if that understanding needs to be shared with a larger group then it falls short.  A detailed requirements document may achieve the goal when it was written, but as time passes the understanding erodes and the requirements that were recorded may become obsolete.

Regardless of the context and the choice of requirements approach, you need to keep the overall goal in mind and use it as a test:
Does everyone have the same understanding of what this work means?
How you get there is up to you!

4 comments:

R1chbloke said...

A shared understanding across a distributed team is all the more crucial. How have the distributed teams you worked on deal with this?

And did you work in a distributed team where most of the team are fresh to Agile?

Dave Rooney said...

Generally, the best way to get that understanding for distributed teams is to temporarily eliminate the distribution. Get as many people as practical together in one place for requirements and/or design workshops. Over time the need to be in the same physical space may diminish as the people build relationships across sites.

As for distributed teams that are new to Agile, it's even more important to physically get together.

If the cost of doing this is a concern, consider the cost of not doing it. For example, what will the rework due to misunderstood requirements cost,?

Jonathan Babcock said...

I love this post, Dave. I think often we get too caught up in the form and mechanics of specifying requirements and forget that the most important thing is do create that crucial "shared understanding" using whatever communication tool(s) suits the situation best.

By the way, I also like your "practical" site name!

Regards,
JB

ktfm said...

I like this article and the fact that is points to the overall purpose of requirements. I believe in coming up with a requirements format that suits the situation best as well as supports whatever test cases need to be created and executed.