Iteration planning is an important time-boxed event designed to drive three outcomes:

• The team determines what items or features they can build in the next iteration.
• The team develops detailed task level plans, describing how to get those items, to meet the Definition of Done.
• The team commits, individually and collectively, to the work that they will accomplish together during the iteration.

Two weeks is usually the ideal timeframe for an iteration (or sprint) because:

• It is realistic for the team to plan and commit to what they can get done in that timeframe.
• It increases the effectiveness of improvements based on feedback loops and validated learning.

How POA Helps Iteration Planning

Iteration planning is dependent on having enough product backlog items (PBIs) prioritized and that meet the Definition of Ready, for the team to commit to building, in the upcoming iteration. This preparation happens during backlog refinement.

Iteration Backlog Refinement = Ready PBI's

"Definition of Ready" is an agile concept that applies to ensuring enough information about a PBI is completed to be able to implement it, in an upcoming sprint. The team defines what needs to be included in a PBI to ensure that it is:

• Clearly articulated and understood,
• Achievable, and
• Testable.

Work does not start on any PBIs unless they are in a "ready" state. During iteration backlog refinement, the Product Owner introduces the PBIs to be considered within the next 1 to 2 iterations and discusses the acceptance criteria. This is a structured, collaborative meeting to ensure that the team understands the value of the PBI and has enough information about the PBI to be able to commit to the work. Iteration backlog refinement conversations include:

• Architecture and design considerations,
• Risk, assumption, and dependency considerations,
• Quality, test preparation and test data considerations, and
• Requirement and elaboration considerations.

The team asks probing questions about the PBI that will help POA Practitioners update the level of detail needed in the acceptance criteria to get the PBI to a Ready state. When the team is satisfied that they have enough understanding of the work, the PBI is estimated, and the status is set to "ready for iteration planning."

Iteration Planning = PBI Commitment

Iteration planning is a structured session that is held after iteration review and retrospective, and before starting the upcoming iteration.

Participants include:

• Delivery team,
• Product Owner,
• POA Practitioners, and
• Any contributors that were identified during iteration refinement to build a PBI for the iteration.

At the beginning of the session, the team agrees to:

• Iteration goal(s),
• A brief description of the theme,
• Features, and
• The Ready PBI's targeted for the iteration work.

The team continues to reiterate the customer value and benefits. For the remainder of the meeting, POA Practitioners are available to answer clarification questions. The team collaboratively self-organizes to task out the PBI work while balancing items selected with team velocity.

At the end of the session the team:

• Affirms a shared commitment to the iteration goal that is:
  • clearly understood,
  • compelling, and
  • measurable.
• Commits to a set of:
  • PBI's aligned to the iteration goal, and
  • Estimated tasks associated with each PBI. (The team owns the commitment to the iteration backlog, and they decide what is doable.)

POA Techniques for Iteration Planning

Agile Extension Techniques

• Backlog Refinement: Ensure there is enough detail and clarity for items in the backlog so that the delivery team can complete an iteration.
• Behaviour Driven Development (BDD): Focus on the intended customer behaviour to
  • Increase value,
  • Decrease waste, and
  • Increase communication between stakeholders and delivery teams.
• Planning Workshops: Determine what value can be delivered in an iteration.
• Spikes: Accelerate understanding of PBIs by investigating or researching concepts, novel ideas, or user stories.
• Story Elaboration: Define the detailed design and acceptance criteria for a story to deliver a working solution.
• Story Mapping: Sequence the stories planned for an iteration and track progress over the iteration.

BABOK® Guide Techniques

• Business Rules Analysis: Identify, validate, and express rules governing the functionalities included in the iteration.
• Data Dictionary: Assess the impact or added entities to the underlying data model for the product in an iteration.
• Non-Functional Requirements Analysis: Ascertain that the product quality parameters are as expected in the iteration.
• Prototyping: Quickly demonstrate value, or elicit information, about the stories slated to be developed in an iteration.

Other Techniques

• Definition Concepts (Ready, Delivery, Done): Use to determine if an iteration meets all the defined and required criteria.

Case Study: Plan Iteration - Food Manufacturer

Background Once release planning was completed, Poultry Plus' Product Owner, Tony, needed to work with the product development team to plan specific tasks at a more detailed level for the New Project Intake Process effort. He worked with the Scrum Master, Joanne, to set up agile ceremonies for their team to use to drive their work. Challenge The team had recently come together based on a reorganization at Poultry Plus. Some had not worked together in the past. They were building a brand-new application and did not have a solid sense of the work that would be required. They had to: Work together to determine how much work could be done in a sprint, Commit to completing it, and Deliver at least a demonstration of what had been completed each sprint. Action When the team reviewed the backlog in detail, they realized that: It was not arranged according to the releases previously planned, and they adjusted it accordingly, and They needed to further refine the backlog by adding tasks to cover additional technical discovery. This would ensure that the design required for the stories was completed correctly and efficiently. Tony led the team in reviewing the user stories for the first iteration capturing customer contact and company information. Some of the stories were vague, They were not certain of how to fulfil the needs, e.g. Did the customer names require salutations, or just first and last names? How should addresses be formatted? Would they need multiple contacts or just one? These questions were referred to the Analysts to elaborate the stories. There were questions on usability, which led to a discussion on non- functional requirements, including: “When would the system need to be available to the customers?” “Would they need to be authenticated users of the system, or could just anyone enter a new project request?” Outcome Fortunately, the sales team had quick answers for the product development team. They sat down the next day to plan the first sprint. Although many of the team members had not worked together before, several had the experience of developing a similar application and could apply their expert judgment to the estimates. They began by: Selecting tasks that were foundational for others to build, Estimating the sizes of the tasks by comparing them to one another, Setting estimates in hours, and Committing to only tasks they estimated could fit into their two-week sprint. Tony prepared an email to the business stakeholders confirming the functionality that would be demonstrated at the end of the sprint. Lessons Learned There was a temptation to assign the tasks and have the individuals assigned provide an effort estimate. Joanne cautioned the team that while individual estimates may be quicker, agreeing as a team on estimates for each task would enable them to better estimate over time, especially as different Developers would take on various tasks over the course of the project. The team found that planning as a team helped: Keep them honest, and Gave them suggestions from each person's experience, to shape the estimating process. Although time-consuming, they found that taking the time at the outset of the first sprint, saved them time on subsequent sprints. The team decided that: Once the first sprint started, the analysts would take on the next set of prioritized stories, and They should ensure that they were appropriately elaborated prior to the next planning session. This way, they would not lose time going back to the business stakeholders to get more details.

As an outcome of focused, collaborative, committed Iteration Planning, the team builds and delivers PBI's. The product features emerge and evolve by consistently building small, manageable value increments, and adapting increments through learning. This is accomplished with consistent and regular support from the Product Owner.

How POA Helps Build Product Features

The team should be confident in the quality of the product planning to self- organize and begin the work of building the product increment. The Product Owner should step back and let the team do their best work. During the iteration build, the primary role of the Product Owner is to be available.

Questions, clarifications, or decisions, which may not arise until the actual PBI work is started, need quick action from the Product Owner. Otherwise, the PBI may not get done.

The Product Owner should join daily stand-ups to stay in tune with the progress of the iteration and learn of any challenges, or questions, that need to be resolved.

In parallel to the team's iteration work, POA Practitioners:

• Refine the product backlog to prepare for future iterations,
• Provide clarity to any questions from team members,
• Communicate with customers,
• Participate in PBI reviews, and
• Prepare for the upcoming iteration review.

POA Techniques to Build Product Features

Agile Extension Techniques

• Reviews: Collaboratively explain and discuss issues, stories, and work related to the iteration with the product team.

Case Study: Build Product Features - Food Manufacturer

Background The releases and iteration were planned, and all the user stories elaborated and detailed to the satisfaction of the New Product Intake Process effort. The Developers were ready to complete their tasks. Product Owner Tony was excited to see what would be delivered in two weeks' time. Challenge Now was the time to make sure that the Developers had what they needed to execute their tasks effectively, with a minimum of roadblocks and with access to the tools and resources they needed. Action Scrum Master Joanne scheduled meetings for 15 minutes every morning to: Get a quick assessment from the team on work completed the day prior, and Review work planned for the current day. Product Owner Tony attended the daily meetings and was available to address any roadblocks or help the team. Outcome Tony and Joanne stood aside and let the Developers do their work. Lessons Learned One benefit of being able to step aside from the day-to-day task work for Tony was that his time was freed up to: Work on the backlog to get it ready for the next sprint's refinement activities, and At a strategic planning level, provide detail at a lower level for future releases. This allowed the Developers to use their time more effectively.

One of the benefits of agile product delivery is the frequency of validating product features throughout the product development lifecycle.

• In waterfall SDLC's, validation of product features occurs near the end of the lifecycle, just prior to production release, when it is typically too late to influence changes.
• Agile product delivery integrates validation iteratively, inviting feedback and promoting learning opportunities and changes. This helps increase the value of the product that will be delivered. Product features are validated through:
  • PBI Acceptance, which is solely done by the Product Owner.
  • Iteration Reviews, expanding the validation opportunity to include
    • Stakeholders
    • Users
    • Customers
  • User Acceptance Testing, which integrates actual users, customers, or representatives of the customer, to validate product functionality and features.

How POA Helps Validate Product Features

PBI Acceptance

POA Practitioners should review the PBI's when the team sets the status of the PBI to “done”. This review includes the:

• Product Owner
• Developer
• Tester

Others may need to be included to add value to the review, like POA Practitioners or an Architect.

The Product Owner has the option to accept or reject the PBI. By reviewing the PBIs as they are done, prior to iteration review, the team may be able to address any issues that would cause the Product Owner to reject the PBI before the end of the iteration. Through conversation with the team, they will determine if the work can be completed. If it cannot, the Product Owner will add the change to the Product Backlog for revision work in the next iteration.

Iteration Reviews

The Product Owner facilitates the iteration review ceremony at the end of the iteration. POA Practitioners can support this work. 30/70 or 20/80 are good guides to balance the time spent on the kick-off and the PBI demonstrations.

The Product Owner:

• Ensures that the right participants are invited to gather meaningful feedback.
• Helps the team to prepare to showcase the work completed. Even things like technical PBI's can be creatively demonstrated to show how they contribute to customer value.
• Highlights how the work completed builds on previous work to show progression.
• Kicks-off by sharing:
  • Information about the iteration that may include a story.
  • An overview of PBI progress within the iteration, and relative to the release.
  • The status of each committed PBI with an explanation of anything that did not get done.
• Orchestrates the demo of each PBI, which may be done by the Developer, Tester, Business Analyst, or the Product Owner, themself. Enabling the delivery team to demonstrate and showcase their work contributes to their sense of pride and puts them closer to the customer and stakeholders.
• Sets the stage for feedback, gathers feedback, asks clarifying questions to understand feedback, and requests further discussion if needed.

User Acceptance Testing

The Product Owner helps to facilitate frequent opportunities for users to participate in testing. Getting feedback from users or potential users gives meaningful insights that influence the released product. Showcase events are often used in place of a formal user acceptance testing, or as a prerequisite to improve the quality of what will be reviewed.

POA Techniques to Validate Product Features

Agile Extension Techniques

• Reviews (e.g., 3 Amigos, Iterations): Collaboratively explain and discuss issues, stories, and product-related work to iteration with the Developer and QA (for 3 amigos). Iteration review includes a broader team and a larger agenda with an evaluation of the entire iteration.
• Definition Concepts (Ready, Delivery, Done): Agree if PBI item is “done” according to agreed-upon criteria.

Case Study: Validate Product Features - Food Manufacturer

Background Toward the end of their first sprint, the New Project Intake Process team was almost ready to demonstrate the customer and company contact features they had developed. The new application had the requested functionality but did not have the company look and feel. Still, the team was anxious to validate what they had produced. Challenge The team needed validation from the business stakeholders that the functionality developed over the sprint was correct. If it was not, then they needed to analyze what was and adjust. If adjustments were needed, they must be considered in the next sprint, when prioritizing work. Action The team agreed to use the Acceptance Criteria on the user stories as the basis for their Definition of Done. In this case, since the final look and feel of the application was not available, Product Owner Tony suggested that for this sprint, the Definition of Done could be limited to everything in the acceptance criteria except the look and feel. As long as the specified functionality worked as agreed, they could count the development successful. Tony asked the business stakeholders to bring their laptops to the sprint review meeting so they could take the new functionality on a test drive. The development team had the application set up in a test environment so they could provide a demonstration and then turn it over to the business team to try it. They demonstrated the way a customer would: Sign up for an account, Log in, and Provide their contact and company information. They allowed the business team to perform the same tasks. One of the business stakeholders, Laura, asked if there was a way for a customer to have more than one contact person. Customer projects were so large that customers needed to interact with a team of people, not just one point of contact, she reasoned. Outcome Product Owner Tony reviewed the related user stories and did not find a specification that more than one contact could be established per project, although more than one contact could be associated with a particular company. Tony agreed that they would: Develop new stories to cover this requirement, and Prioritize for the upcoming sprints. Lessons Learned New or missed requirements can arise from a demonstration and user acceptance testing. It is important to recognize that even though such requirements could be viewed as "missed" or that they render the functionality presented as incomplete, the delivery for the sprint can be considered "done." When this occurs, it is critical to communicate with the team that the new or missed requirements will be addressed in a future sprint. Care should be taken to point this out the next time the backlog is reviewed.