The biggest drawback of agile development I have experienced is that people not involved in development focus on the mantra that a user story (3-10 ideal person days) should not contain more than 1-3 sentences like:
As a customer, I can use free-text search so that I can find the products I'm looking for.
Giving this sentence, project managers expect me as a developer to commit to an estimate and develop the story. They assume that agile development means that sentences like this are all they have to provide to developers.
I won't blame them because the well-known literature about agile development creates the impression that this would actually work. I've read something like 2 pages in natural language per story in "Planning XP", but that's it. Because "working software" is favored over "comprehensive documentation", this topic seems to be generally avoided.
The reality is, of course, that if the developer is given the chance to do so, an interview with the customer brings up a long list of requirements that the customer has about the story:
- We need boolean operators like AND and OR.
- We need fuzzy search an all terms.
- We need to search by single words as well as by phrase.
- We don't want to find products that meet criteria X, Y, and Z.
- We want to sort the result. Oh, and by the way, the user can select the sort criteria in a combo box with options a, b, and c.
So you see that I'm not talking about technical details or software design or even implementation details. It's pure requirements. The longer we talk the more the customer realizes that there's actually quite a lot to say about what they want.
But often enough I find myself in the situation that such information is not provided or in very shoddy fashion. Neither is it possible that I do the interview, nor does the person that would be in the position to do the interview provide me with a result of it.
Sometimes, managers even come up with technical details like "we want Lucene search" but they don't want to think about if they want find only product names or also product descriptions. Sometimes I think they are just lazy 😉
For me, this is the top issue in projects I work in (e-business web application, 500-2000 person days per project). I've addressed this problem often enough, and managers are aware that most developers have a problem with the situation. But they believe that developers are just too much "perfectionists". They seem annoyed that developers "always want to have everything specified".
Due to the lack of generally acknowledged numbers it's hard to argue. Everybody knows how long an iteration should be. But nobody can tell how much requirements are needed to estimate and develop a story.
Do you have some reference?
Best Answer
You're missing the point of agile a little bit. What you are calling a user story, I see as at least six: one bare-bones search, and one for each of your bullet points. By all means, make enough plans to avoid painting yourself into a corner that's going to be expensive to get out of, but the whole idea is that you provide the minimum needed to deliver some value, and do it quickly enough to get rapid feedback.
When you divide a story up like that, it not only makes it easier to estimate, it allows the product owner to prioritize in a more fine-grained manner. Certainly they like the ability to sort the search results, but maybe it's not as important as another item on the backlog that's completely unrelated to search.
Also, on the idea of programmers needing everything specified, try to look at it from the customer's point of view. A lot of times, it's like you're going in to buy a car, and the salesman is asking what color you want for the windshield wiper knob. A lot of details we might find important are completely irrelevant from a customer point of view. I've worked where requirements are highly over-specified, and trust me, it is not very fun. The kind of latitude you're complaining about, a lot of programmers would love to have.