On Monday, May 17, 2010, from 1:00 p.m. – 2:00 p.m. Eastern time (18:00-19:00 UK time),  Tom Grant, Ph.D. from Forrester Research will host a teleconference on Requirements Tools.

“…the adage “the right tool for the right job” definitely applies to requirements tools. We have segmented the requirements tool market by the business problems that they address.”

Teleconference Agenda:

• The ROI of requirements tools
• Different business problems, different tools
• How the needs of IT and TI differ
• Recommendations and next steps

You can find more information about this event at http://www.forrester.com/rb/teleconference/requirements_tools_address_different_business_problems/q/id/6281/t/1. A teleconference registration fee may be required.

I was working with a customer this week doing a process diagnostic. One of the things they happened to mention is that they miss waterfall. I was surprised as these days all I hear is how everyone wants to be more agile.

I asked for more, and the anecdote provided was that they cannot get commitment to specific Features being delivered as part of a release as they could in the past. Their requirements process had migrated from Features to User Stories where if they asked for a Feature the first response was give us the stories and then when asked when they can get the features they were told “when it’s done”!

Now of course, for any company where success is meeting market needs, this is not desired. So after that phase of the diagnostic was complete, I mentioned we could help them create an environment where Features and Stories can coexist and a release commitment could be created. I do not see this as breaking agile simply making it work in an environment where the Product Owner needs to meet the team’s needs but also the needs of a commercial company where commitment to stories is not enough. Do you agree?

Q1: What are the top three Requirements/Features in your next product release?

Q2: How do the top three help address your long-term product strategy?

Q3: If you had been planning this release six months ago or six months from now, would the top three still be the same?

I have often found it easy to answer question 1, and not so easy to answer 2 and 3. If my boss asks me to answer 2 or 3 I would stall or if forced say something like “We should not do that; we are an agile company, our priorities change every day”.

But is that right? Is saying our priorities change every day almost the same as saying “Everything is a Priority”? Shouldn’t we strategize, prioritize and plan? One noted expert in the field, Karl Wiegers, states: “One characteristic of excellent requirements is that they are explicitly prioritized.”

Of course, any discussion of business priorities today has the following adages behind it:

1. In today’s world, you have to be agile, so we have to be fluid and accept change
2. In this economy, we are end-of-quarter driven, so priorities change each quarter

I observe the above but do not accept requirements change WITHOUT communicating the impact of making the change. In other words, state something like “Yes, we can consider that change and we should understand its impact on ________ and ________”

To help others make the decision, I find it is very helpful to list the pros and cons in two columns, it doesn’t hurt this method is ascribed to Benjamin Franklin:

An investment in knowledge still yields the best returns. – Benjamin Franklin

People will accept your ideas much more readily if you tell them Benjamin Franklin said it first. – David H. Comins

(image courtesy Blackberry Studio)