Agile teams struggle with successfully applying agile approaches to project planning and delivery. In particular, an area that needs to be explored is negotiating customer commitments within an agile process. Common to agile processes is delivering customer value in short cycles and small increments. Customer commitments are made for each increment and meeting these small commitments early in the project will build the trust that is crucial in order for agile to be successful. In this article, I will explain the key steps, and practices within each step, that will assist in making and delivering on customer commitments in an agile fashion.

Intention: To Provide a Road Map for an Agile Iteration
At SolutionsIQ, we have had enormous success mixing Scrum and Extreme Programming to provide a complete agile process. Throughout this article, terminology is kept generic in an effort to allow practitioners the opportunity to adjust terms to their desired process. The intent of this article is to present an agile process to lead a team from iteration planning to delivering upon those customer commitments.

Setting the Stage
As a team member on a new project where the customer needs to know what will be done and when, but we want to do in an agile way. While using an agile approach how do we plan and commit to delivery while keeping scope and priorities flexible?

The Key Steps:

• Using, sizing and selecting Stories for an iteration
• Transforming the list of stories into a contract with the customer
• Tracking iteration progress
• Delivering
• Adjusting the process

Using, Sizing and Selecting Stories for an Iteration
Stories are the basic unit of planning. You should review the INVEST acronym (Independent, Negotiable, Valuable, Estimable, Small, Testable) for instructions on how to create well formed Stories. [1] The important point here is that Stories must include success criteria that represent the negotiated scope and commitment between the customer and the team.

Each iteration starts with a meeting to go over the Stories that will be completed.

Goal: Derive an iteration commitment that is accepted by the team and the customer, that everyone on the team agrees can be completed within the iteration, and that also represents significant progress towards the overall objectives.

Prior to the planing session:

1. Work with the customer to define well-formed Stories.

2. Have the customer prioritize the Stories.

3. Ensure that the team agrees on a Velocity based on the total number of estimation points completed in the previous iteration adjusted to account for holidays, vacations, meetings, etc.

Tip: If this is your first iteration or you are using a new estimation unit, select a Velocity that is one third of the expected capacity. Often the team will stabilize at a ratio of Velocity equaling half capacity.

During the planning session:

1. Explain the Velocity number to the customer, which may have been adjusted for holidays, etc.

2. In priority order, have the customer explain the Stories and then allow the team to ask questions.

3. As soon as an estimate can be derived, stop discussing and vote. Avoid deep dives and design debates that are wasteful at this early stage. Respect the customer's time.

4. Work with the team to agree on an estimate and reduce the available Velocity.

5. Stop estimating when the Velocity number is reached.

6. Review the Stories for the iteration and gain agreement

Note on Estimating: Use a strategy like Planning Poker to ensure that the whole team is involved. [2] Avoid design debates and try to agree on a potential solution, just to get the estimate done. During the iteration, whoever selects the Story will determine how to implement it. Review the Lean concept of making decisions at the Last Responsible Moment. [3] This is also why I suggest avoiding breaking Stories down into Tasks during planning, as it locks in the implementation too early.

Transform the List of Stories Into a Contract with the Customer
The customer should feel confident that the team will achieve what it signed up to do.

Goal: Make sure everyone is comfortable and aligned with the iteration objectives.

Ending the planning session: This is a critical point as the whole team is now committing to deliver on this set of Stories at the end of the iteration. Use the Fist of Five or other voting strategy to ensure that the confidence is high. [4] Then, conduct some type of ritual, like signing a contract. This lets everyone know that the commitment is accepted and will be treated with respect.

Tracking Iteration Progress
The customer should be kept informed on how well the iteration is going. A customer that understands the Product Owner role will be happy to be involved daily as long as he sees benefit derived from the investment. The customer should never be surprised at the end of the iteration.

Goal: Involve the customer in adjusting the plan to match reality as it happens.

Daily cycle:

1. Start the day with a Standup, and encourage the customer to attend.

2. Review the impediment list and blocked Stories with the customer, and update the resolution plan.

3. Review the iteration progress and remaining work.

4. Allow the team to arrange assignments for the workday, who is working on what, who needs help, etc.

5. Do quality work and have fun.

Story overrun : Having a Story take longer than expected is a common risk to an iteration's commitment. First, try to identify the problem as early as possible. This is easier with small Stories since it will become obvious sooner if it is taking longer than expected. Once the problem is identified do whatever is possible to keep the Story on track.

The following is a prioritized list of agile ways to address an overrun:

1. Raise the issue to the customer and ask for assistance in resolving the problem.

2. Find a way around the blocking issue through a team discussion.

3. Back up and start over - don't be afraid to throw away dead-end work.

4. Try a different brain on the problem - pass the Story to others for a fresh perspective.

5. Reduce the scope - try to find a quicker solution that is still acceptable to the customer.

6. Move on to another Story and come back after all other Stories are done.

7. Split the Story into one table for the current Sprint and one for a future Sprint.

8. Drop the Story from the Sprint - and preferably substitute a small Story that can be done instead.

Note on Meeting Commitments: No matter how well informed the customer is, he will feel letdown when the team does not meet the original commitment. If the team signs up for eight Stories then do your best to complete eight Stories. Breaking the commitment will lower trust and make it harder to be successful with agile.

Delivering
Before moving to the next iteration, validate this iteration's delivery and reflect on the iteration.

Ending the Iteration:

Goal: Celebrate the successful completion and discuss how it went.

1. Select a facilitator who will ensure that everyone is involved and provides input.

2. Review the original commitment and how it was adjusted during the iteration.

3. Perform a demo of the completed Stories.

4. Enjoy the success. The team and the customer should be excited by what was accomplished.

5. Conduct a retrospective, what went well, ways to improve - and keep it positive and honest.

Tip: a scorecard can help collect the team's feedback and the customer's satisfaction.

Adjusting the Process
The best part of using an agile process is the built-in feedback and adjustment cycles. How can you go wrong with a process that tunes itself?

Goal: Determine the ways to provide higher value in each iteration.

Team process improvement:

1. Review the process and make adjustments -- the afternoon after an iteration ends is a great time to do this.

2. Start with the results of the retrospective and the list of adjustments from the last process review.

3. Discuss what improvements to make for the next iteration and gain full team agreement.

Conclusion
Being agile is not easy for a new team. A team that is learning the agile way of life should start by closely adhering to proven end-to-end agile practices. Do not simply string together a selection of easy to implement low hanging agile practices that are painless to implement. Agile requires discipline and the courage to stick with it as the change will be challenging. Following the practices explained in this article will allow the team to adopt agile in a proven way that will support a successful transition to agile and early buy-in from both customers and management. Soon, the team can evolve this simple process into a more customized and personal version of agile that meets the context's specific needs while continuing to meet customer commitments.

About the Author

Lance B. Young has over 15 years of software development experience in a wide range of projects using traditional and agile methodologies. Lance began using agile development practices nearly ten years ago and has been using XP, with or without Scrum, exclusively since that time. Currently Lance is the Director of Delivery Excellence at SolutionsIQ, an IT software development and consulting firm in Redmond, Washington. Lance has led the introduction and implementation of agile best practices for more than twenty teams. He is a regular presenter at national conferences including agile 2006 and agile 2007 and an agile evangelist at a number of technical and process groups including the XP user group, Seattle Java user group, and the Seattle APLN. Lance is currently focused on designing and rolling out an agile Enterprise that utilizes agile approaches in all business areas from software projects to sales and marketing.

[1] Bill Wake. "INVEST in Good Stories, and SMART Tasks" (http://xp123.com/xplor/xp0308/index.shtml)

[2] Mike Cohn, agile Estimating and Planning (Robert C. Martin Series), Prentice Hall, 2005

[3] Mary and Tom Poppendieck, Lean Software Development: An agile Toolkit Chapter 3, Defer Commitment

[4] Jim Schindler "Meeting Facilitation: Important Ingredient for Change"