Using features allows customers to define what they want at a higher level than the developer might. For instance, if you are working on a travel web site, one requested feature might be "Allow Customers to Save a trip for future purchase". Many Agile practitioners like to break a feature like this into more detail for the developers. This detail takes shape as appropriate tasks or stories. The team defines the tasks or stories once the customer selects that feature for the next iteration. It would create waste to define those tasks and stories before they were selected. Features originally created may not be selected ever, so spending any more time on them would be waste. Only work on what the customer has requested, do not over engineer.
In the first customer planning meeting with the team, the customer will select the first features to work on. Being the first meeting, the team will not demo anything, since the customer has selected any work items. The team leader (most likely) explains the meeting structure to the customers/stakeholders that meet in the planning demo meeting. This includes standard project management issues like the communication plan (daily standup meetings, planning meetings), change management (planning meetings allow the customer to change their minds on priority without a lot of ceremony). The first meeting also must have the customer understand the type of work items the team is using.
The customer needs to understand that they are in charge of priorities. The customer and team define what is meant by done for this project. By definition of done, XP prefers that the customer helps the team define an automated acceptance test that the team can use. The first meeting will normally take more time than the standard planning meeting, so set the meeting time accordingly.
Passing the automated test does not mean that the feature is complete, but that it is ready to be included in the release. It is recommended that done means that feature is released version. In a web site, if it could be released to production, that would be best.
Length of Iterations or Releases
Iterative development is the clarion call of Agile development now. I actually do not know what clarion call means, but thought it added some flavor to this article. The point being that most articles etc. associate Agile with fixed length iterations. But Agile is really about short feedback cycles, not necessarily fixed length iterations.
To clarify, fixed length iterations are defined by the time allocated for the team to finish selected features/stories. The number of stories selected are based on the teams past performance. So if a team has consistently finished two features in an iteration of two weeks, the customer can select two features for the next iteration. During that fixed iteration, the customer cannot change the feature selection.
Lean development methods recommend a different approach to iterations. Instead of fixed length iterations, the team commits to release frequently, in a time frame similar to fixed length iterations. But the customer prioritizes all the features, rather than selecting a set number of features for the iteration. Team members, who have finished their task, story or feature, pick the next highest priority from the backlog.
For release or fixed length iteration, the team decides the length of either. The recommended length is normally one to four weeks. Shorter is considered better, since the length of the iteration determines the feedback cycle. Many do not like one week length times, but the shorter time frame can help focus the team.
Make a team room! This cannot be emphasized enough. There is literature that points to the benefits of team rooms. The benefits include close communication between team members. The team can also have fun, which can't be discounted.
Surprisingly, many team members may want initially to work in their cube, rather than in a team room. While the team should be self directed, make a pitch for this, it is worth doing. The team may not pair program, but the ability to immediately lean over and look at someones code for answers helps speed the team. Also, with everyone working out in the open in the same room, without a personal phone close by, multi tasking is discouraged.
The team room should be a conference room, or a "war room" type area, that can comfortably house the team. For large teams, the team room, may be split into multiple rooms, like <A>feature crews</A>.
The team should decide about unit testing. TDD is recommended but the discipline may not be available in the team. Start out requiring unit tests for all features. A team meeting with some examples of good TDD and unit testing examples can help the team to understand this practice. If this practice is not new to the team they have a head start.
Automated Acceptance Testing is recommended as well. This means that the customer will need to commit to helping to understand/write tests. This is a recommended best practice that will help in years to come as changes are made to the application. With automated acceptance tests, change in business logic that contradict older business logic are easily spotted. These can be clarified with customers before they go to production.
Look at Fitnesse, rSpec, and Selenium as some open source options for automated acceptance tests. You can try using this without software costs, just time costs.
So how does the team know if their work items are the right size? One way to answer this is to use the planning poker method, popularized by XP. Planning poker allows the wisdom of crowds to help give an estimate.
To use this method, first admit that our estimates are wrong. I do not know any software estimates that are consistently accurate as to amount of time. But if a team does estimates using a metric like a point system, the work items estimated tend to reduce variability over time.
To estimate using planning poker, teams sit together and they vote on the size of each story. If there is a story like "A Customer can log in to check their latest orders shipping status", each member of the team votes on the effort to complete that story. Many teams use the Fibonacci sequence as a way to "score" each story. That sequence starts as 1, 2, 3, 5, 8, 13, 21 ... Another method is called shirt sizing. Shirt sizing uses measures like Small, Medium, Large or some variation of sizes. The number does not mean time, but it does represent level of effort to the team.
I recommend the book "Agile Estimating and Planning" by Mike Cohn, as a good starting point on Estimating. As your teams mature, there become better ways to estimate, to eliminate much of the time spent on estimating. There is much discussion on this topic in lean software development circles.
Once your team has been working for a few weeks, their estimates should show consistency. The team sees how many points they complete per iteration or release. Over time that number will smooth out to be very consistent. Occasionally the team encounters difficulties such as new technology, or domain specific issues that slow them down. But over time, the number that can be completed is consistent.
Now that your team has jumped into using Agile methods, the journey is not over. The idea of using Agile/Lean ideas is to continuously improve your processes. Keep in mind that customer value is key to provide, and keep your people who add value in the center of that process. Agile and Lean methods push responsibilities down to the team level, so embrace that philosophy.