Starting Scrum
The first step in Scrum is for the Product Owner to articulate the product vision. Eventually,
this evolves into a refined and prioritized list of features called the Product Backlog. This
backlog exists (and evolves) over the lifetime of the product; it is the product road map
(Figure 2). At any point, the Product Backlog is the single, definitive view of “everything that
could be done by the Team ever, in order of priority”. Only a single Product Backlog exists;
this means the Product Owner is required to make prioritization decisions across the entire
spectrum, representing the interest of stakeholders and influenced by the team.
Figure 2. The Product Backlog
The Product Backlog includes a variety of items, primarily new customer features (“enable all
users to place book in shopping cart”), but also engineering improvement goals (“rework the
transaction processing module to make it scalable”), exploratory or research work (“investigate
solutions for speeding up credit card validation”), and, possibly, known defects (“diagnose and
fix the order processing script errors”), if there are only a few problems. (A system with many
defects usually has a separate defect tracking system.) The Product Backlog can be articulated
in any way that is clear and sustainable, though either Use Cases or “user stories” are often
used to describe the Product Backlog items in terms of their value to the end user of the
product.
The subset of the Product Backlog that is intended for the current release is known as the
Release Backlog, and in general, this portion is the primary focus of the Product Owner.
The Product Backlog is continuously updated by the Product Owner to reflect changes in the
needs of the customer, new ideas or insights, moves by the competition, technical hurdles that
appear, and so forth. The Team provides the Product Owner with estimates of the effort
required for each item on the Product Backlog. In addition, the Product Owner is responsible
for assigning a business value estimate to each individual item. This is usually an unfamiliar
practice for a Product Owner. As such, it is something a ScrumMaster may help the Product
Owner learn to do. With these two estimates (effort and value) and perhaps with additional
risk estimates, the Product Owner prioritizes the backlog (actually, usually just the Release
Backlog subset) to maximize ROI (choosing items of high value with low effort) or
secondarily, to reduce some major risk. As will be seen, these effort and value estimates may
be refreshed each Sprint as people learn; consequently, this is a continuous re-prioritization
activity as the Product Backlog is ever-evolving.
Scrum does not define techniques for expressing or prioritizing items in the Product Backlog
and it does not define an estimation technique. A common technique is to estimate in terms
of relative size (factoring in effort, complexity, and uncertainty) using a unit of “story points”
or simply “points”.
Over time, a Team tracks how much work it can do each Sprint; for example, averaging 26
points per Sprint. With this information they can project a release date to complete all features,
or how many features can be completed by a fixed date, if the average continues and nothing
changes. This average is called the “velocity” of the team. Velocity is expressed in the same
units as the Product Backlog item size estimates.
The items in the Product Backlog can vary significantly in size or effort. Larger ones are
broken into smaller items during the Product Backlog Refinement workshop or the Sprint
Planning Meeting, and smaller ones may be consolidated. The Product Backlog items for the
upcoming next several Sprints should be small and fine-grained enough that they are
understood by the Team, enabling commitments made in the Sprint Planning meeting to be
meaningful; this is called an “actionable” size.
One of the myths about Scrum is that it prevents you from writing detailed specifications; in
reality, it is up to the Product Owner and Team to decide how much detail is required, and this
will vary from one backlog item to the next, depending on the insight of the Team, and other
factors. State what is important in the least amount of space necessary – in other words, do not
describe every possible detail of an item, just make clear what is necessary for it to be
understood. Low priority items, far from being implemented and usually “coarse grained” or
large, have less requirements details. High priority and fine-grained items that will soon be
implemented tend to have more detail.
Ref from: Pete Deemer ScrumTI.com
The first step in Scrum is for the Product Owner to articulate the product vision. Eventually,
this evolves into a refined and prioritized list of features called the Product Backlog. This
backlog exists (and evolves) over the lifetime of the product; it is the product road map
(Figure 2). At any point, the Product Backlog is the single, definitive view of “everything that
could be done by the Team ever, in order of priority”. Only a single Product Backlog exists;
this means the Product Owner is required to make prioritization decisions across the entire
spectrum, representing the interest of stakeholders and influenced by the team.
Figure 2. The Product Backlog
The Product Backlog includes a variety of items, primarily new customer features (“enable all
users to place book in shopping cart”), but also engineering improvement goals (“rework the
transaction processing module to make it scalable”), exploratory or research work (“investigate
solutions for speeding up credit card validation”), and, possibly, known defects (“diagnose and
fix the order processing script errors”), if there are only a few problems. (A system with many
defects usually has a separate defect tracking system.) The Product Backlog can be articulated
in any way that is clear and sustainable, though either Use Cases or “user stories” are often
used to describe the Product Backlog items in terms of their value to the end user of the
product.
The subset of the Product Backlog that is intended for the current release is known as the
Release Backlog, and in general, this portion is the primary focus of the Product Owner.
The Product Backlog is continuously updated by the Product Owner to reflect changes in the
needs of the customer, new ideas or insights, moves by the competition, technical hurdles that
appear, and so forth. The Team provides the Product Owner with estimates of the effort
required for each item on the Product Backlog. In addition, the Product Owner is responsible
for assigning a business value estimate to each individual item. This is usually an unfamiliar
practice for a Product Owner. As such, it is something a ScrumMaster may help the Product
Owner learn to do. With these two estimates (effort and value) and perhaps with additional
risk estimates, the Product Owner prioritizes the backlog (actually, usually just the Release
Backlog subset) to maximize ROI (choosing items of high value with low effort) or
secondarily, to reduce some major risk. As will be seen, these effort and value estimates may
be refreshed each Sprint as people learn; consequently, this is a continuous re-prioritization
activity as the Product Backlog is ever-evolving.
Scrum does not define techniques for expressing or prioritizing items in the Product Backlog
and it does not define an estimation technique. A common technique is to estimate in terms
of relative size (factoring in effort, complexity, and uncertainty) using a unit of “story points”
or simply “points”.
Over time, a Team tracks how much work it can do each Sprint; for example, averaging 26
points per Sprint. With this information they can project a release date to complete all features,
or how many features can be completed by a fixed date, if the average continues and nothing
changes. This average is called the “velocity” of the team. Velocity is expressed in the same
units as the Product Backlog item size estimates.
The items in the Product Backlog can vary significantly in size or effort. Larger ones are
broken into smaller items during the Product Backlog Refinement workshop or the Sprint
Planning Meeting, and smaller ones may be consolidated. The Product Backlog items for the
upcoming next several Sprints should be small and fine-grained enough that they are
understood by the Team, enabling commitments made in the Sprint Planning meeting to be
meaningful; this is called an “actionable” size.
One of the myths about Scrum is that it prevents you from writing detailed specifications; in
reality, it is up to the Product Owner and Team to decide how much detail is required, and this
will vary from one backlog item to the next, depending on the insight of the Team, and other
factors. State what is important in the least amount of space necessary – in other words, do not
describe every possible detail of an item, just make clear what is necessary for it to be
understood. Low priority items, far from being implemented and usually “coarse grained” or
large, have less requirements details. High priority and fine-grained items that will soon be
implemented tend to have more detail.
Ref from: Pete Deemer ScrumTI.com
No comments:
Post a Comment