Get Developers thinking in terms of Features EARLY

Developers aren't used to thinking in features at the beginning of projects. They are usually so engrossed in the details that they immediately start thinking of the tasks they need to do in order to build a piece of software.

Show them a mockup of a screen, give them sample data and whatever else they need, and developers will immediately list their tasks:
1) Create database schema
2) Normalize schema
3) Create middleware
4) Create screen

etc.

The problem is that users and BAs (and everyone else who rolls onto a project after it's started) talk in terms of features. There is a fundamental communication problem.

So how do you effect this transition of language that developers speak from tasks -> features?

As a BA, specify to the developers that you want a first round iteration of software that does the bare-bones. Pick the 2 or 3 important pieces of functionality; intentionally limit the scope and let 'er rip! If developers come back with something they feel is too complicated or unknown, defer it. The BA should be able to specify EVERYTHING in the first iteration. There should be no loose ends. This allows the developers to go away and code; if they have questions, the BA can answer them and if need be, further limit the scope.

Now, let's say the developers have done their part and delivered a working piece of software for the first iteration. If the BA gets a few people (including people who may not even be on the project) to put their eyes on the software along with the developers who created the software, those people will give a tremendous amount of feedback.

But these people (who may or may not be developers themselves) will naturally start talking about what the software lacks or needs more of or could be better, etc. They'll be speaking in terms of FEATURES! The developers who hear this then start to think in terms of features.

The cool thing about having a working piece of software is that once it works, there is tremendous incentive to keep it working! If developers implement something that breaks the software, they'll back up and fix it! Once you have running software, you're not thinking in terms of tasks to get the software up and running. Now you're thinking of what new features you can add! This allows IT to organically grow the software to fit user needs; and not to create something big, ugly & over-complicated that was never needed in the first place. This can easily happen when you're in 'design' mode and thinking in terms of tasks.

Once the developers start thinking in terms of features, then they'll think about the tasks they need to get it done on their own. But now the channel has been crossed; BAs, PMs and Developers can start talking in the same language: in terms of features. The sooner this transition happens the better. What's required is getting that first working iteration out the door.

As well, talking via 'features' makes everyone naturally more delivery-focused. Features add value and customers are able to naturally relate to that; they'll instantly understand what you're talking about.