Purpose:
Enable teams to work collaboratively, deliver value incrementally, and adapt to changing requirements by providing a structured approach with defined roles, events, and artifacts, allowing them to efficiently manage complex projects while delivering high-quality products in a timely manner, all while embracing transparency, inspection, and adaptation as core principles.
Objective:
to deliver high-value product increments in short iterations (called sprints) by fostering collaboration, continuous improvement, and flexibility within a team,
Description:
Agile Scrum methodology combines the Agile philosophy and the Scrum framework. Agile means “incremental,” allowing teams to develop projects in small increments. Scrum is one of the many types of Agile methodology. It’s known for breaking down projects into sizable chunks called “sprints.” Agile Scrum methodology is good for businesses that must finish specific projects quickly.
Agile Scrum methodology is a project management system that relies on incremental development. Each iteration consists of two- to four-week sprints, where the goal of each sprint is to build the most important features first and come out with a potentially deliverable product. More features are built into the product in subsequent sprints and are adjusted based on stakeholder and customer feedback between sprints.
While other project management methods emphasize building an entire product from start to finish in one operation, Agile Scrum methodology focuses on delivering several product iterations to provide stakeholders with the highest business value in the least amount of time.
Agile Scrum methodology encourages faster product development because each set of goals must be completed within each sprint’s time frame. It also requires frequent planning and goal setting, which helps the Scrum team focus on the current sprint’s objectives and increase productivity.
Entrance Criteria:
<?>
Exit Criteria:
Process and Procedures:
Tailoring Guidelines:
None
Process Verification Record(s):
Measure(s):
- Cycle time
- Lead time
- Throughput
- Work in progress
- Work item age
- Flow efficiency
- Blocked time
- Team morale
-
- Defect removal efficiency
- Escaped defects
Cumulative flow diagram
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
Control chart
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Release Burndown
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Epic Burndown
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
- Velocity
- Maintained By: <?>
- Submitted By: <?>
- Frequency of Submission: <?>
References:
Define the Objectives of a Release
Objectives are concrete statements that describe what a release is trying to achieve. An objective should be written so that it can be evaluated after a release to see whether it was achieved. A well-worded objective will be Specific, Measurable, Attainable / Achievable, Realistic, and Time-bound (SMART). (SMART is a technique for wording the objective. An objective does not have to be SMART to be valid.)
An example of an objective statement might be to “upgrade the customer service telephone system by August 15 to achieve average client wait times of no more than two minutes“.
- Note that the objective is specific
- The objective is measurable regarding the average client wait times the new phone system tries to achieve.
- You can assume that the objective is achievable and
- The objective is time-bound and should be completed by August 15.
Objectives are completed through the creation of release deliverables. In the example, the objective refers to upgrading the telephone system. Suppose you cannot determine the deliverables that are created to achieve the objective. In that case, the objective may be written too high. On the other hand, if an objective describes the characteristics of the deliverables (such as speed or ability to handle a specific number of users), it is written at too low a level. Characteristics tend to be more requirements statements, not objectives.
Suppose the release is part of a program. In that case, the objectives of all the release deliverables should align with the program objectives.
Objectives show an agreement between the Agile Team and the Product Owner on the primary purpose of the release. For example, the specific deliverables of a release may or may not make sense to the Product Owner. However, the objectives should be written so that they are understandable to all product stakeholders.
Objectives are also valuable since they provide alignment to organizational goals and strategies. A PPO should not authorize a release not tied to goals and strategies.
