There are times in an agile development process when we need to recall some traditional tools from what might be called "traditional waterfall software development."

We've all been there. Some feature is coming up that's either technically complex or politically charged. It might be both. I suspect it is often both.

Perhaps it's been looming out there for quite some time. Yes it has.

There's no clear, defined consensus about what it's for. What is the true scope of this feature? What technologies are available to accelerate the development of this thing? Are there exmples we can learn from? Are we trying to change the nature of the very concept behind this thing?

Perhaps we've already sold it to someone. Perhaps it's not even clear what it is we've sold. We can start iterating and doing research stories, but meanwhile the pressure builds. When will we have it? Will it deliver what has been promised? How much will it cost?

This kind of situation can lend itself to a more traditional set of SDLC controls. Stop what you're doing and take a step back. Ask your team a few questions:

Can you define the marketing and sales requirements (aka the cutomer requirements) for this new thing?

Can you match some hard, clear use cases to those market requirements?

Do you have alignment in your core team on answers to the above questions?

Can you say what it is and what it isn't? Do all parties say more or less the same thing about what it is and what it isn't? Does that match what's been sold?

Do you have resources who can do research on what's possible?

Are your functional requirements based on answers to the above questions?

Are you technical requirements based on answers to the above?

Do your have an approved budget now that you know what it is?

Can you now use an agile approach to execute against these requirements?

Of course, this looks more like a task list than a set of questions, but that's just the way these things go.