By technical necessity

By whichever means the Product Owner determines will yield the greatest value in the next release

By risk

By development cohesion

By business value

Shu

Ha

Ri

The Scrum Team and key stakeholders invited by the Product Owner

The Scrum Team and any key stakeholders invited by the Product Owner

The Product Owner and key stakeholders invited by the Product Owner

The Development Team and the Product Owner

4 weeks

6 weeks

Due to the nature of an agile project, the expected time cannot be projected

3 weeks

Inspection, adaption, transparency

Inspection, projection, transparency

Projection, adaption, transparency

Inspection, adaption, projection

Fixed date, variable scope

Fixing both the scope of the project as well as the date

Fixed scope, variable date

Allowing both the date and the scope of the project to be variable

The Product Backlog is adapted to reflect any newly discovered changes in the direction of the product.

The stakeholders of the product receive an opportunity to provide early feedback and influence the direction of the product.

The stakeholders of the product receive an opportunity to select the items the Scrum Team will be working on in the next Sprint.

The Product Owner receives validation on the direction of the product.

Each team's individual Product Increment will be integrated into a single Product Increment in a final hardening Sprint prior to release.

Each team's individual Product Increment should be integrated into a single Product Increment before the conclusion of each Sprint.

All teams will collaborate to integrate their respective Product Increments in an integration Sprint that occurs every three Sprints.

Separate Definitions of Done should be created for the server related code and the user interface related code. Teams should adhere to the Definition of Done that's most appropriate for the type of code they are working on.

Each team should create their own Definition of Done but make their definition visible to other teams so that differences can easily be identified and planned for.

A single Definition of Done for all work will be defined by the Integration Team. All Scrum Teams must adhere to this definition in order for their work to be integrated.

All teams should create and agree on a shared Definition of Done that represents the criteria necessary for their combined Product Increment to be considered releasable.

To ensure that the Development Team holds the event and that the Sprint Burndown chart is updated accurately.

To provide an update of what the Scrum Master did yesterday, what he will be doing today, and what is in his way.

To record the status update of each individual team member so it can be discussed in the Sprint Review.

To ensure that the Development Team holds the event and adheres to the 15 minute timebox.

Two Product Backlogs should be created, one for user interface items and one for server items. Teams should pull from the Product Backlog that best represents the type of work they are doing during that Sprint.

The master Product Backlog should be split into three evenly sized child Product Backlogs. Each team should pull the top item from each child Product Backlog in turn to ensure even coverage.

All teams should work from a shared Product Backlog.

Each team should create their own Product Backlog that can be managed independently of the other teams.

5 minutes per Product Backlog item scheduled for review

8 hours for a 1 month Sprint, proportionately shorter for shorter Sprints

4 hours for a 1 month Sprint, proportionately shorter for shorter Sprints

4 hours for a one month Sprint, proportionately shorter for shorter Sprints.

As long as is necessary for the team deliver all work forecasted for that Sprint.

Up to one calendar month.

A Sprint ends only once the Sprint Goal has been achieved.

No more than 6 weeks for a project with an annual release cycle, proportionately shorter for projects with shorter release cycles.

Forming, Storming, Norming

Forming, Norming, Storming, Performing

Forming, Storming, Norming, Performing

Forming, Storming, Conforming, Performing

Iterative Development

Rapid Application Development

Incremental Development

Structured Development