When someone asks me for an estimate I try to invert the conversation to talk about investment.
When they ask how long you think it will take, they are really asking: How much should I expect to invest in this in order to get a decent return from it?
If you can surface this question instead you can help them explore the expected return, and it becomes a straightforward return-on-investment discussion rather than the traditional estimation-as-contract negotiation.
One of the ideas in lean product development is the notion of set-based concurrent engineering: considering a solution as the intersection of a number of feasible parts, rather than iterating on a bunch of individual “point-based” solutions.
This lets several groups work at the same time, as they converge on a solution.
The goal is not necessarily to deliver features or business functionality.
Perhaps you can create business impact by suggesting those two people in different buildings sit next to one another.
Now the miscommunication that caused the problem that prompted the original system request goes away.
Immediate impact with no software!
(…) simplify the first feature until you can make everything you need emerge from the TDD cycle.
Then iterate (polish the existing behaviour) and increment (add new behaviour) in small steps until the system performs what you initially thought was the first feature.
The trick is to slice big requirements into smaller steps, each of which has some value & lets you learn something about the problem and your solution.
In the GOOS example we do this.
The entire example is really just one feature (an app that bids in auctions), but we break the implementation down into small slices to let a suitable domain model emerge through refactoring.
We use the to-do list to keep track of things we discover along the way, which we then implement later in the example.