A Release is typically composed of four to five 2-week sprints, each of which delivers tested software. A collection of several sprints makes up a go live release to deliver one or more journeys. Every Sprint begins with Sprint Planning, when the Scrum team meets to agree on a Sprint goal and determine what it can deliver during the forthcoming Sprint. For the initial release, we plan on delivering with out of box functionality while building the integration points as we prepare for the initial release. This strategy enables you to quickly see business value. Once that is done, we start configuration and development for customized case types and prepare for the next release.
Sprint Planning is a key activity in Scrum, when the Scrum team meets to review the prioritized Product/Case Type Backlog, and determine which Backlog items can be ‘pulled’ into the current Sprint. When planning a Sprint, it is important to be mindful of the Scrum team’s capacity in the Sprint, adjusting for any planned time off or other variables. This helps ensure that the Sprint goals and the subsequent commitment to the Sprint output is realistic and reasonable.
A Product Backlog may represent many weeks or months of work over multiple sprints and releases. To determine the most important subset of Product Backlog items to build in the next Sprint, the Scrum team performs Sprint Planning, where the Sprint goal is defined, and the development team determines the specific items from the product’s MLP to deliver by the end of the Sprint.
The development team creates a plan for how to deliver the Product Backlog items which meet the Scrum team’s Definition of Ready (DoR). This means the User Story is refined, has documented and well-understood Acceptance Criteria, and is sized, estimated, and prioritized by the Product Owner. The development team breaks down the User Story into a set of tasks, which, with the Sprint goal, become the Sprint Backlog.
Published May 8, 2018 — Updated March 12, 2019