Matt Bilotti has a great post titled How We Build Products at Drift. The crux of the article is that there’s a new, and better, way to do software development: burndown. Today, in the startup world, agile is the most common software development methodology. Only, it’s centered around the two week sprint, and the reality is that the customer feedback loop is much faster than two weeks.
Here’s the breakdown on agile vs. burndown from the post:
- Measure of success
- Agile – Thoroughness of story, agile points and velocity
- Burndown – End user feature adoption & retention
- Means of determining prioritization
- Agile – Product backlogs and sprint planning
- Burndown – End user validated design mockups and prototypes.
- Speed
- Agile – Story-based sprints (weeks)
- Burndown – Micro-sprints (days)
- Release focus
- Agile – Multiple features grouped into a single release version
- Burndown – A single version of a single feature per release
- Flexibility
- Agile – 2-week sprints are planned, executed & generally inflexible once agreed upon
- Burndown – Every day priorities change and so do the current and upcoming sprints
Feel like the agile software development methodology isn’t quite right for your team? Consider trying out some of these burndown concepts.
What else? What are some more thoughts on agile vs. burndown methodologies?
David Cummings on Startups 
Burndown makes a lot of sense and looks more agile than the agile software methodology listed above, which sounds like scrum.
We do one to two week sprints but leave plenty of room for bringing in new work and tackling the most important work. Often the most important and unplanned is directly related to a customer’s need or issue. I look forward to reading the next post from the Drift team.