In an agile environment we use a nice term for deadlines: agile timeboxes. Deadlines can be terribly demotivating. In many projects I know of, deadlines were the very first constants defined. But deadlines can be helpful or even necessary. Product managers love deadlines, of course. Fixed dates allow the coordination of technical dependencies or involved stakeholders.
There is nothing wrong with deadlines or timeboxes, if setup wisely. I worked in projects, where even passionate agile developers said that deadlines helped them to keep pace.
The problem with timeboxes is, that they often are not thought-out well enough. Typically it goes like this:
- Set the deadline (some call it timebox)
- Discover what you want to do within that time frame
- Work hard, work late
- Realize that you cannot complete in time
- Rush to finish, rip out some “unnecessary” features, sacrifice quality
- Be late (optional)
- Launch crappy work
For us user experience designers this quite a mess. Since rather quality gets sacrificed than time or budget gets increased to make it in time, many of our carefully crafted parts that actually just make the product get cut off: “We can fix that later!”. It’s not unusual that there is already another timebox waiting, so even that fixing will never happen.
Timeboxes can be useful, if they align with scope nicely.
The question you should ask is not: “How many features can we get done before the deadline?” but rather: “What timebox do we need to build the essentials of the product?”.
Simply put: Before you did not discover what you want to do, you cannot predict a reasonable timeframe for what to do.
Of course, the bigger the scope, the harder it gets to have reliable estimations. But in general, to make a timebox useful and the final product valuable and usable, I suggest considering the following approach:
- Frame business and user goals
- Initiate product discovery to define product requirements and support goals
- Commit to essential parts of the product (including ux requirements!)
- Set size of timebox together with your team
- Estimate (secretly) a time buffer, just in case
- Work relaxed
- Launch success
Who would want to build a car and launch it to market by saying: “Sorry, we did not have enough time to build the steering wheel”. Makes sense?!