Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
The official Scrum guide has been updated this month, and as site's page states, " represents the official Scrum Body Of Knowledge, (that) was written by Ken Schwaber and Jeff Sutherland, co-creators of Scrum". In other words, this is Scrum's equivalent of the PMBOK of the PMI.
At 17 pages, it is 30 times smaller than the PMBOK, but no less richer in it's method of project delivery. Here's some of the major changes to the guide as outlined the co-founders Jeff Sutherland and Ken Schwaber:
- The team working on an increment is the Development Team (All team members will be known as Developers regardless of their roles)
- The Development Team does not commit to completing the work planned during a Sprint planning meeting
-
Scrum does not mandate a burndown chart to monitor progress, but these two progress metrics should be updated
- Remaining work for a Sprint that is summed and updated on a daily basis
- Trending toward completing the work of the Sprint is maintained throughout the Sprint
- Release planning is not a requirement of Scrum
- The Sprint Backlog is the Product Backlog items selected for a Sprint.
- The Product Backlog is "ordered", instead of "prioritized"
The core of Scrum did not seem to change at all, but rather some finer points were clarified. But much like the PMBOK, it is a body of knowledge or best practices that is left up to the practitioner to implement. For those doing Scrum it's a must to review in detail.
The
team
of
people
performing
the
work
of
creating
an
Increment
is
the
Development
Team.
Regardless
of
the
work
performed
by
individual
team
members,
they
are
known
as
Developers.
• Development
Teams
do
not
commit
to
completing
the
work
planned
during
a
Sprint
Planning
Meeting.
The
Development
Team
creates
a
forecast
of
work
it
believes
will
be
done,
but
that
forecast
will
change
as
more
becomes
known
throughout
the
Sprint.
• Scrum
does
not
mandate
a
burndown
chart
to
monitor
progress.
Scrum
requires
only
that:
• Remaining
work
for
a
Sprint
is
summed
and
known
on
a
daily
basis.
• Trending
toward
completing
the
work
of
the
Sprint
is
maintained
throughout
the
Sprint.
• Release
Planning
is
a
valuable
thing
to
do
when
using
Scrum,
but
isn’t
required
by
Scrum
itself.
• The
Sprint
Backlog
is
the
Product
Backlog
items
selected
for
the
Sprint,
plus
a
plan
for
delivering
them.
There
is
no
longer
a
required
concept
of
“Sprint
Backlog
items”
although
that
technique
can
make
a
great
plan.
A
self--organizing
Development
Team
always
has
a
plan.
• The
Product
Backlog
is
“ordered,”
instead
of
“prioritized,”
providing
flexibility
to
the
Product
Owner
to
optimize
value
in
his
or
her
unique
circumstances
The$team$of$people$performing$the$work$of$creating$an$Increment$is$the$Development$Team.$
Regardless$of$the$work$performed$by$individual$team$members,$they$are$known$as$Developers.
• Development$Teams$do$not$commit$to$completing$the$work$planned$during$a$Sprint$Planning$
Meeting.$The$Development$Team$creates$a$forecast$of$work$it$believes$will$be$done,$but$that$
forecast$will$change$as$more$becomes$known$throughout$the$Sprint.
• Scrum$does$not$mandate$a$burndown$chart$to$monitor$progress.$Scrum$requires only$that:
• Remaining$work$for$a$Sprint$is summed$and$known$on$a$daily$basis.
• Trending$toward$completing$the$work$of$the$Sprint$is$maintained$throughout$the$Sprint.
• Release$Planning$is$a$valuable$thing$to$do$when$using$Scrum,$but$isn’t$required$by$Scrum$itself.
• The$Sprint$Backlog$is$the$Product$Backlog$items$selected$for$the$Sprint,$plus$a$plan$for$delivering$
them.$There$is$no$longer$a$required$concept$of$“Sprint$Backlog$items”$although$that$technique$can$
make$a$great$plan. A$selfGorganizing$Development$Team$always$has$a$plan.
• The$Product$Backlog$is$“ordered,”$instead$of$“prioritized,”$providing$flexibility$to$the$Product$Owner$
to$optimize$value$in$his$or$her$unique$circumstances.
Posted on: July 31, 2011 07:12 PM |
Permalink