Agile Planning Essentials

Agile Release Planning involves quantifying the pace that a team can develop user stories into working software. The team’s velocity is the measurement of its throughput which is used to establish expectations regarding future delivery dates. To establish delivery dates, we examine the total amount of work for the project and divide it by the established team velocity. We then gauge how many iterations are needed to deliver the entire project. For example, if we have 100 story points to complete for the project and the team’s velocity is estimated at 15 points per iteration, we calculate the number of iterations needed as follows:

• Total Effort/Estimated Team Velocity = Number of Iterations
• 100/15 = 6.66 = 7 iterations

Release Planning

Release Planning involves a commitment to plan the delivery of a product increment of value. The Scrum team is responsible for planning the releases. Table 1 describes the responsibility of the team during this ceremony.

Role	Responsibility
Scrum Master	Facilitator for the Release Planning meeting
Product Owner	Outlines the contents of the Product Backlog
Delivery Team/Agile Team	Discusses technical feasibility and dependencies
Stakeholders	Trusted Advisors for decisions made about the release plan

Table 1. Release Planning Roles and Responsibilities

What Happens Before the Release Meeting?

Prior to the start of the Release Planning meeting, the Product Owner needs to ensure that the Product Backlog has been prioritized. The Scrum Team should provide input about capabilities, velocity and any technical impacts. The vision statement, market and business objectives should be established. The Product Owner, if applicable, needs to announce whether new product backlog items will be needed.

Release Planning Data and Output

In terms of needed data for the Release Planning meeting, data from previous Sprints and releases would be beneficial. Stakeholders typically, but not always, provide feedback about the product, market conditions and proposed deadlines. Also useful are Action Plans and goals from previous releases and retrospectives. There may be additional items and unresolved defects that should be revisited. The team should be on hand to discuss relevant development and architectural information. In addition, the team’s estimated velocity based on previous iterations should be considered as well as input from other technical team and subject matter experts to properly manage dependencies. The output from Release Planning includes but is not limited to the following:

• Release Plan
• Team Commitment to the Plan
• Suggestions for improvement regarding future Release Planning meetings
• New user stories for the Release Backlog

We found these books great for finding out more information on Agile Scrum:

The Sprint Planning

Every Sprint start with a Sprint Planning meeting. All team members should be present because this is the chance to determine how much work can be completed in the upcoming Sprint. The Guide to the Scrum Body of Knowledge (SBOK Guide) suggests that A one-month Sprint Planning Meeting has two parts and is time-boxed to eight hours:

1. Objective Definition – This event occurs during the first half of the meeting where the Product Owner discusses the highest priority User Stories in the Prioritized Product Backlog to the team. The Scrum Team then defines the Sprint Goal.
2. Task Estimation – This event occurs during the second half of the meeting where the Scrum Team determines how to finish the work in the Sprint Backlog to meeting the Sprint Goal.

The User Stories are estimated, approved and committed. Each Scrum Team members participates in an estimation of the tasks using common techniques such as Planning Poker. In the case of where the estimating is lengthy, it would mean that the team was not totally prepared to start the Sprint. Effort Estimation is used to select the tasks that are needed to complete the work. The Sprint Backlog is created as well as the establishment of the Burndown Chart and the development team commitment is made verbally.

There are two events that should not occur during a Sprint Planning meeting:

1. The refinement of the User Stories that should be done prior to the Sprint Planning Meeting.
2. Updates or Revisions – The User Stories should be clearly defined and ready to be broken down into tasks and then estimated. Updates to the User Stories should not occur during Sprint Planning.

Iterations Length

The length of an iteration should not be longer than six weeks. The length of the Sprint is the determining reason as to how fast the Scrum team can inspect and adapt to fluctuating situations and continuing to learn. By having a maximum length for the Sprint, the Scrum Team is practically guaranteed a minimum benefit.  If a Sprint is longer than six weeks, the benefits of Scrum are lessened. Risks have the potential to be increased because of short term planning, adapting to change, the development of the team, detection of errors and the timing of business opportunities.

Task Estimates to Story Points Story Points represent a high-level estimation of complexity that is used prior to Sprint Planning. Story Points and velocity are relative measures that provide agreed upon guidelines about the user stories that will be committed in the iterations. On the other hand, task estimates based on hours are very low-level estimates that are used to represent the specific effort in hours that will be required to complete the User Stories during a Sprint. Tasks estimates should be as accurate as possible whereas Story Points are never expected to be exact. Since story points and task hours are used for very different purposes for different situations, the attempt to make a correlation between the two is not recommended.