Focus on the what's and why's and avoid the how's when writing the user stories.
What you're faced with is actually a very good exercise for all developers. Being able to express the requirement in simple, business terms is an important skill.
You should focus on the general requirement such as "need to be able to make a single selection from a drop-down listing of objects so the user can enable Foo action" instead of specifying using a combobox or listbox or whatever that triggers a specific routine.
Another way of approaching this is pretending like the underlying code base / framework is almost complete black box. Any time you find yourself saying "use object XYZ", you can self-check by asking if you would know of that in a black box system.
Update:
IMO, it's okay to put details into a use case that indicate the level of detail required for information. For example, with an enrollment system it's fair game to specify
- last name; required field
- first name; required field
- account ID; system generated no input necessary
- astrological sign; optional field - (suggestion) provide lookup from entering birthdate?
- etc....
The key is that you are not specifying the technical how for that information. If you find yourself saying "use a String class / character array / or varchar field" for last name, then you know you are over-specifying.
If you're multi-lingual, then use two disparate languages as your litmus test. For example, strings in C are generally char(acter) arrays whereas C++, Java, and C# (okay, and almost everyone else...) have an actual String like object. If you find that your specification is invalidated by using one of those languages then you'll know you've over-specified.
It's worth noting that I'm specifically using the term Use Case as opposed to User Story, although the variant I end up using is a hybrid of both. My goal of a use case is to give an overview of what's going on (a User Story in the strictest sense) but then work through the actors, systems, and general functionality that's required. My approach is closer to what Fowler is suggesting in that wikipedia article as opposed to Cockburn's approach.
So I'll have a single use case (or so) for the enrollment scenario or work item. If it's really complex, I would break it out into multiples, but that's not a big deal. The use case can then be broken down into individual tasks as necessary. What's tossed into a particular scrum depends upon lots of variables, but there's nothing within this approach that prevents you from having a demonstrable component at the end of the scrum.
