Agile Engineering

Story size should be based on what you need now. Stories in the current iteration should be small enough that you can commit to them and finish them throughout the iteration. No larger than half the iteration. I'd lean to more like 1-3 days. Large stories put the iteration at risk. Small stories help you establish flow / quick feedback as you get things done.

Stories are the fuel for your agile engine. Your team takes them as input and transforms them into business value. If your stories are lacking, it can really wreak havoc on your engine and your results.

How agile are you? Are you doing the common agile practices but missing the point behind them? Here are three questions to ask yourself:

Are you focusing on the things that will have the greatest impact on the business?

A major goal in agile is to stay releasable. Do a little. Get feedback. Do a little more. In fact, a great question to ask is what would prevent you from releasing what you have now? The answer can help you highlight areas where changes might have a significant benefit. Look at each thing, prioritize it relative to the others and then try to change so that each item is handled during each iteration.

There's a notable difference between working for a start up and working for a large company. One major distinction is focus. Start ups that aren't focused don't tend to last long. Large companies can afford to go many directions at once. But they often do so at a cost. By fighting against themselves with cross purposes they lose some of the leverage that their size could provide.

Stories represent business value. If you accomplish them, it will help the business. Tasks, on the other hand, are a means to track what must be done to accomplish those stories. They can be really helpful in communicating what work remains and coordinating on who does it.

Quick. What's the point of estimating stories? If you said determining how long they will take to implement, you only got part of the equation. In addition to helping the team to project the contents of future iterations, estimation can be an invaluable way of getting the team up to speed quickly on what is coming soon.

Iteration demos are a great way to show the progress that the team is making. They can help to keep the extended team up to date on the state of the application. They can generate feedback on where to go next. A few tips to get the most out of them:

Your organization has skills and areas of knowledge. Each person (or group) is good at something. You might take this to mean that the best strategy would be to give them something to work on that matches that expertise. That seems most efficient. Give them something they're good at and they'll get the most done, right? It depends on how you define efficiency. If it's how much they output per unit of time, maybe so. If it's how much business value they output per unit of time, maybe not.

Many companies claim to be agile. If you look at their practices, a lot of them are pretty far from what most would consider ideal. Where do you draw the line? What threshold do you have to cross to claim agility?