I am working on an application that has a number of hierarchical datagrids. There is a need to specify the relationship, for instance, when you are adding an element to that hierarchy. Currently we allow the user to add an element as either a sibling or a child of an existing element. There is a lot of concern that the terms sibling and child are to development speak and not user friendly. Are there other terms that would be more user centric?
You should use language with which the user is familiar so call the elements what the user calls them. A user who is familiar with the system or the context of the system will immediately understand the terms that are used and will inherently know the underlying structure.
For example, a system for visualising the hierarchical structure of species of animal would be best using the kingdom > phylum > class > family* names for it's elements as these would be immediately recognisable by the users and they would inherently know what structure they represented. A user wouldn't add a new child of a phylum, they would add a new class and pick the phylum it belonged to inherently knowing what was about to happen. This would be much better than calling them all parents of some and children of another. I would bet a user in that context would find parent and child naming a uneccessary cognitive load.
This is actually a fundamental Nielsen Norman UI Design Heuristic:
You might be in a situation where you cannot get this information from your users, such as a groundbreaking system or one with a huge diverse market, in which case the best terms you are going to come across are terms like parent and child, which are words that decsribe a widely understood structure.
Add/Remove "Row" is the quick answer. You're just adding rows, don't get bogged down into terminology semantics because in the end you're dealing in a situation with a lot of overloaded UI patterns anyway. keeping in generic at the very least let's the users force their behavior into them defining problems to your team in a way that they can express their overall intent differently..
Long answer. I deliberately held back on investment in DataGrid controls for WPF/Silverlight when they first came out because the behavior that these controls provide is essentially what i'd call a UX crutch for the mass .NET developer(s) world wide. When a developer is in a situation where they've built a UI that emulates Excel's behavior you have to really ask yourself the question out loud "Why are they always re-inventing Excel and always coming up short on the experience anyway?"
Hierarchy datagrids are an overload in cognitive load, as not only do you have grouping issues attached but you're also trying to merge two patterns under the one control so then trying to unpick the whole terminology point is essentially in many ways "moving the deck chairs around on the titanic" - at this point it really doesn't matter as its highly likely you're not solving the end users actual data problems anyway (that or you'll likely find they'll start trying to game you into rebuilding them excel through a series of trickled in "feature requests").
Now you could also be the exception to the above rule, but i'll be honest after managing an entire UI platform i can honestly say its been a long while since i've seen this pattern not get abused this way?