If a reporter gets the lede wrong, then the article is not only difficult to write, but it will inevitably be muddled and muddy to read. Newspaper folk call this "burying the lede." In software development, we often "bury our promise." We tend to focus too much on the software features or functional requirements—the concrete stuff—at the expense of the higher-level requirements that the customer and users really care about. It happens just as much in agile projects as it does in other types of projects.
Just as a reporter will figure out an article's lede by asking what the article is really about and then use the lede to guide him as he writes, software development projects need to ask not what its lede is, but what promise they are making. What's the project really about? How will the project's customers and the team's bosses judge if it is successful? I like my teams to agree on a one- or two-sentence "promise" with their customers. Last year, for instance, I ran a project where our promise to the team's management was simply to "rebuild trust with the customers." A few years earlier the promise was even simpler: "Do what you've got to do to beat our competitors to market with a good quality product."
A clear promise, like a good lede, sets the stage for everything that follows. Just as the reporter will scrutinize every sentence to ensure that it fits with the lede, a project's staff must always keep the promise in mind when making a decision. For instance, a month into the first project, we had some bad news which we could easily have hidden from the customer, but when I asked myself "Will this rebuild trust with the customer?" I decided that no, I would actually build more trust by sharing the bad news. Likewise, we quickly decided that the second project would deliver a very austere, but functional, product rather than one that was all singing and all dancing. Why? Because the product, the higher our odds of keeping our promise and beating our competitor into the market place.






