I just returned to the UK from Australia – the flight wasn’t too bad, I am sure you’re up for the commute.

I’d love to come work with you but the commute would kill me.

Maye you could run a requirements limerick competition as a promotion? I’ll be in the entries.

Thanks for making me laugh!!

thanks for the critique, I need to explain that further.
I do not distinguish between business requirements on one hand and functional requirements on the other.
I destinguish between functional vs. scalar on one hand, and business vs. system on the other.
The first pair is in KIND OF requirement (or type, of you prefer), the second pair is in LEVEL OF requirement.
you wite that business requirements tend to be fluffy, and I agree. I think that this is a problem, like with any requirement that is not expressed clearly. we should avoid that at all cost.
So breaking requirements (all kinds and levels) down to short statements is a good idea, generally.

Good discussion anyway!

Rolf

I saw another one on Alistair Cockburn’s blog; requirements in the form of Haiku or Limerick.

Email Excel files
To team leaders every day
Showing sales pipleines

or maybe

A team leader received a report each day
With someting important and useful to say
It arrived in a mail
In the form of excel (wince)
And showed all the sales on their way

After everyone’s feedback, I think that the best solution is to use some kind of indicator, rather than an actual limit. I like your screenshots from Tweetdeck, we will probably go for something like this as it is quiet unobtrusive, but will still stop us from rambling too much!!!!!

I’m inclined to have to say I’d be against programatically enforcing an artificial limit. There may very well be good reasons for exceeding the limit on occasion. To quote Einstein, “Everything should be made as simple as possible, but not simpler.” I like to incentive to be as simple and concise as possible, but I’m not overly keen on having an analyst have to oversimplify to fit a requirement into a character limit.

I think I’d let the analyst type away, but much like Tweetdeck and probably other Twitter applications, I’d give the user a visual indication (change text or background color, or something not overly intrusive) that they’d exceeded 140 characters, only I wouldn’t truncate the requirement if they decided to keep it a little longer.

I’ve posted a couple sample pics from Tweetdeck in my response on Practical Analyst to illustrate if you’d like to have a look there: http://practicalanalyst.com/2009/06/03/bright-idea-on-requirement-character-limits/

Interesting topic!

Yes we defined the value for each individual story or backlog item. And whenever possible in the perspective of the user. Quite honestly, this was probably more enlightening for me as I guided the requirements process than anyone else. It helped me ensure we stayed focused on what was really needed instead of what was simply wanted. It also helped when reviewing the backlog with the dev team as they would propose some alternative solutions or have other ideas. We could always link that story back to a problem…which has a much broader impact than a specific requirement.

On an interesting side note, there were some stories where the requirements was used by the customer but the internal staff was the one to benefit. (for example, asking the customer to provide a specific piece of information for audit or in-office efficiency purposes) Just the fact we tied the requirement to the benefit helped me keep perspective and side-step some potential rabbit holes.

Given this, you might consider rewriting your requirement as the following:

“As a team lead I receive a daily sales pipeline Excel spreadsheet via email in order to manage my workforce.”

Under 140…I checked in tweetdeck!

I’d probably try to get a bit more specific about how the report would help a team lead manage their sales force….what are they looking for and how will it help them?

Laura
http://bridging-the-gap.com

Thanks for your comment. I agree, the “because” is really important, especially for developers as it really helps them understand why we are asking them to build such things. My reason for taking it out of the requirement is that it is not really a requirement – more an objective or benefit.

I am interested in your experience in the product backlog on your agile project. Are you talking about defining the value for the individual story, or something different?

Adam

I like the idea. But one aspect you cut, the rationale for the requirements (to ensure they can adequately manage their salesforce), is to me important. I started writing requirements as agile backlog items in my most recent project and learned about the need for a “because” for each and every backlog item. Taking time to think through the because leads to better, more focused requirements.

But all in all, the idea of enforcing an artificial constraint to help yourself winnow down bloated requirements and poor language is a good one. It works for all types of writing, including blog posts!

Laura
http://bridging-the-gap.com