Korva is a scroll of the internet’s best ideas.
Give your spec a deadline
What a spec is
A spec is the list of things to build before launch. Capping it with a deadline makes it simpler: if the launch is three weeks out, only what can be built in three weeks makes the list, and every feature that can't be built in that time comes off.
Why to write it down
Writing it down matters because a spec that lives in someone's head drifts. A user says they would never use a feature, or an investor says the idea could never be a company, and the plan shifts without anyone noticing. A three-week plan becomes a three-month plan. A written spec at least makes it obvious how often it is changing.
Cutting the list
A week into a three-week sprint, the spec usually turns out to hold too much. The unimportant items go first, and if none are left, important ones go too, since the aim is to get anything into the world. A product that is out has strong momentum behind it, while one that isn't tends to be delayed again and again.
Why do plans run past their deadlines?
Psychologists Daniel Kahneman and Amos Tversky named the planning fallacy in 1979, describing people's tendency to underestimate how long tasks will take. In a 1994 study by Roger Buehler, Dale Griffin, and Michael Ross, students predicted they would finish their thesis in about 34 days on average, and the actual average was about 56 days. Only around 30 percent finished within the time they had predicted.
Why does work expand to fit the time given?
British writer Cyril Northcote Parkinson opened a 1955 essay in The Economist with the line that work expands to fill the time available, a claim now called Parkinson's law. His examples came from the British civil service, where administrative staff grew even as the Royal Navy had fewer ships. The essay was written as satire, but the observation about deadlines stuck. Parkinson expanded it into a book published in 1957.
How did fixed-length work cycles spread in software?
Ken Schwaber and Jeff Sutherland presented the Scrum method at a 1995 software conference, built around short fixed-length cycles called sprints. Each sprint ends on a set date with a working piece of software, and anything unfinished goes back on the list. The Scrum Guide, which Schwaber and Sutherland wrote, says a sprint lasts one month or less.