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?

Traditionally, we've categorized requirements as "musts", "shoulds" and "frills". In theory, the musts had to be there to ship. But in reality, many of the musts didn't make it. And unless easy or sexy to the developers, you can forget about the shoulds and frills. So who decides which musts make it? In the absence of someone working with the teams to prioritize things to a finer level, it is determined by the order of attack of development. Those not done yet when things start to look bad get thrown out.

Agile solves this problem by ranking the requirements (typically in the form of stories). If you could only have one thing in the release, what would it be? What if you could have two things? Etc. This ensures that you're attacking the most important things first and that if you come up short, it will be the least important things that get left off.

I attend a lot of meetings. That's not a bad thing. Meetings can be very productive. They can be an opportunity to get the right people in the room and quickly make decisions or convey information. But they can also be a waste of time.

Often times in iteration planning teams task out the stories, put people's names on the tasks and have them estimate the tasks. Each person gets an understanding of what they're slotted to take on in the iteration and can then determine if it is reasonable to commit to the iteration content. While the names are often "in pencil" and subject to change based on how the iteration goes, there are good reasons not to put them on there at this point.

One common struggle when adopting agile (particularly in large organizations) is that it can be very difficult to get things done within a short iteration (typically two weeks). Often times, people on the team will push for lengthening the iteration to make it easier to fit things in. There are a few reasons why you might want to avoid this.

It has long been accepted that defects are an unavoidable consequence of developing software. Large software projects tend to keep track of these in a defect management tool with the goal being to keep defects tracked there to a reasonable level (sometimes reasonable is defined as loosely as hundreds of defects). But, is an accumulation of defects really unavoidable? And until a team determines how to avoid them, how do defects fit into an agile process?