Agile is a process framework used to manage complex product development since the early 1990s. Agile is a framework within which you can employ
various processes and techniques. Agile makes clear the relative efficacy of your product development practices so you can improve. The Agile
framework consists of Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific
purpose and is essential to Agile's success and usage.
The Product Owner is responsible for maximizing the value of the product and prioritizing the work of the Development Team.
The Product Owner is the sole person responsible for managing the Product Backlog. The Product owner ensures that the backlog is
visible, transparent, clear to the business, and confirms the Development Team understands items in the Product Backlog to the level
needed to complete the work. The Product Owner is one person, not a committee. For the Product Owner to succeed, the entire organization
must respect their decisions. The Product Owners' decisions are visible in the content and ordering of the Product Backlog.
The Scrum Master is responsible for ensuring the Team adheres to Scrum principles, practices, and rules and ensuring the Product
Owner arranges the Product Backlog to maximize value. They often facilitate Scrum events as requested by the team. They coach the
Development Team in self-organization and cross-functionality, removing impediments to the Development Teams' progress. They also
coach in environments where Scrum is not yet fully adopted and understood, particularly helping employees and Stakeholders understand
empirical product development.
The Team consists of professionals who do the work of delivering a potentially releasable Increment of "Done" product at the end
of each Sprint. Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy
optimizes the Team's overall efficiency and effectiveness. The most effective Teams are self-organizing, persistent, co-located, and
cross-functional with all the skills necessary to create an increment. Optimal Development Team size is specified in the Scrum Guide
as three to nine members, which is small enough to remain nimble and large enough to complete significant work within a Sprint.
The Product Backlog is an ordered list of everything that is currently considered needed by the business and is the single source
of requirements for any changes to be made to the product. A Product Backlog is never complete. The Product Backlog changes as the
product and the environment in which it will be used evolves. As a product is used and gains value, and the stakeholders provide
feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop changing, so a Product Backlog is a
living artifact. Changes in business requirements, market conditions, or technology will constantly drive changes in the Product Backlog.
Product Backlog refinement is the continuous activity of adding detail, estimates, and priority order to items in the Product Backlog
to the specification defined the Definition of Ready. This is an ongoing process in which the Product Owner, Stakeholders, and
the Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised.
Product Backlog items can be updated at any time by the Product Owner, or at the Product Owner's discretion.
The Team is responsible for all estimates. Estimates are based upon the relative level of complexity, uncertainty, and risk.
These relative estimates are commonly reflected with Fibonacci numbers rather than absolute numerical values. The Product Owner
may influence the Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.
If the PBI is too large to be completed within the Sprint it must be split into smaller stories.
The work to be pulled into the next Sprint from the backlog is determined at the Sprint Planning meeting. This plan is created by
the collaborative work of the entire Team answering what can be delivered in the upcoming Sprint and how the work needed to deliver
the Increment will be achieved. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team.
The Product Owner helps clarify the selected Product Backlog items and make trade-offs if necessary. By the end of the Sprint Planning,
the Team should be able to explain to the Product Owner and Scrum Master how it intends to accomplish the anticipated Increment.
The Daily Standup is a 15-minute time-boxed event for the Team to synchronize activities and create a plan for the next 24 hours.
This is a key inspect and adapt meeting. This is done by inspecting the work since the last Daily Standup and forecasting the work to
be done before the next one. The Daily Standup is held at the same time and place each day to reduce complexity. Daily Standups improve
communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making,
and improve the Team's level of knowledge.
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint
Review, the Scrum Team and Stakeholders collaborate on what was done in the Sprint. Based on that and any changes to the Product
Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting,
not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for adaptation improvements
to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.
This is a one hour time-boxed meeting. By the end of the Sprint Retrospective, the Scrum Team should have identified the main improvement
they will implement in the next Sprint. Implementing this improvement in the next Sprint is the adaptation to the inspection of the
Scrum Team itself.
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment
and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Team about what functionality will be in the next Increment
and the work needed to deliver that functionality into a "Done" Increment. The Sprint Backlog is a plan with enough detail that
changes in progress can be understood in the Daily Scrum. The Team modifies the Sprint Backlog throughout the Sprint, and the
Sprint Backlog emerges during the Sprint.
Every day, the Team members update their estimate of the effort remaining to complete their current work in the Sprint Backlog.
This is displayed in a downward sloping graph that is on a trajectory to reach "zero effort remaining" by the last day of the Sprint.
Hence it is called a Burn Down chart. The horizontal axis of the Sprint Burn Down chart shows the time remaining in the Sprint and the
vertical axis shows the amount of work remaining in the Sprint. It shows their progress towards
their goal, not in terms of how much time was spent in the past, but in terms of how much work remains to complete the Sprint.
The Increment is referred to in two contexts. One is the work completed within the current Sprint. The other is an extension of this
includes all Product Backlog items completed during the previous Sprints as well. At the end of a Sprint, the new Increment must be "Done,"
which means it must be in useable condition and meet the Scrum Team's definition of "Done." It must be in useable condition regardless
of whether the Product Owner decides to release it. This is a business decision determined by the Product Owner.
Definition of Ready
Stories must be immediately actionable when pulled into a Sprint. The Team must be able to determine what needs to be done and the
amount of work required to complete the User Story. The Team must understand the "Done" criteria and what tests will be performed to
demonstrate the story is complete. "Ready" stories should be clear, concise, and most importantly, actionable. The Team works with the
Product Owner during Backlog Refinement to help them get the stories into actionable shape. Only then will the Team be able to estimate
how much work any one story will take and how many Points they can take into a Sprint.
Definition of Done
When a Product Backlog item or an Increment is described as "Done", everyone must understand what "Done" means. Although this
varies significantly per Team, members must have a shared understanding of what it means for work to be complete, to ensure
transparency. This is the definition of "Done" for the Team and is used to assess when work is complete on the product Increment.
The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Team's current
Definition of Done.
Contact us today for an
Agile approach to your Business…