Already have an account? Lucky!
Log In

Small "a" agile

We used agile methods to build Lean-to

We think doing things like writing stories, prioritizing cards (stories and bugs) on the backlog, planning iterations, and holding daily check-in meetings (we call them scrums) lead to better results in software development. We've read the books, subscribe to the blogs, and attend the conferences about these practices but in the end we tailor our process to what we think works best.

Stories

Stories or User Stories are what agile software developers call a feature. A story is functionality that has been broken down into a concise idea that can be understood at a glance, estimated and can be built in a relatively short amount of time.

Iteration

Iterations are sometimes called sprints, and are usually fixed lengths of time resulting in a small but complete piece of working software. Multiple iterations combined create releases and ultimately a product.

Plan

A plan is made up the stories and bugs on which the developers are to work. Iterations stack up to form releases and releases are all a part of a plan.

Backlog

Sometimes called a product Backlog, the backlog is a collection of user stories and bugs that have yet to be assigned to an iteration on plan. The backlog is a constantly evolving list of features that are under consideration for including in future development cycles.

Story points, ideal days, estimation units

Hours, days, ideal days (how much a developer can get done in 8 hours without interruption), and story points are all units used in estimating stories and bugs. Some claim points and ideal days are better because they are not based on level of effort. We tend to use days but don't try to get too exact.

Velocity

Project velocity is a measure of the rate your team is delivering functionality. Velocity is calculated by adding up the estimates of all the stories that were completed each iteration.

Burn-up

A burn-up chart tracks how much work is done. There's a line showing how much work is in the project as whole, and this can change. Note that this report requires estimates to be useful.

More information

What's this talk about agile and lean?

Lean-toTM was created by agile software developers for agile software developers but that doesn't mean others can't benefit from it. If you are interested in learning more about the agile methods we have used or these practices in general we have created a handy agile reference page.

Why the name Lean-to?

The name Lean-to™ lends itself to our message of simple, unobtrusive software and tools in a couple of ways:

  1. A lean-to is pretty much the simplest structure you can build to shelter yourself from the nasty elements of the real-world.
  2. It incorporates "lean" into the name, which is a type of manufacturing methodology that closely resemble the agile methods to which we subscribe.