WE’RE GOING AGILE

This organization is committed to agile

transformation, so we can serve people
better. This little book is your handy
reference to our new agile ways of
working: the events, roles, artifacts and
activities which underpin our agile
practice. Through them, we hope to be
more innovative and timely in the way
we provide value.
We understand that agile change can
be hard, so if you have any questions or
concerns about what these practices
mean for you, don’t hesitate to
approach the Transformation Team.
We’re here to help!

THE AGILE - The Transformation Team

BUDDY GUIDE
ABOUT THIS GUIDE 3

Why we’re “going agile” 3

A quick overview 4

ROLES 5
Product Owner 5

Scrum Master 5

Development Team 5

ARTIFACTS 6

The Product Backlog 6

The Sprint Backlog 7

The Increment 8

EVENTS 8
Sprint Planning 9
The Sprint Goal 9

The Sprint 10
The Definition of Done 10
Product Backlog Refinement 11

The Daily Scrum 11

The Sprint Review 11

The Sprint Retrospective 12

METRICS 12

USER STORIES AND THEIR ACCEPTANCE CRITERIA 14

ESTIMATION TECHNIQUES 16

INFORMATION RADIATORS 17

2
ABOUT THIS GUIDE
Improvement
This Buddy Guide has been written to help you get up to speed
quickly with our agile way of working. It is designed to satisfy
the following acceptance criteria: “…we all need to be able

Given people need a clear way of working to observe and improve

When they join an agile team how we do things”

Then they should have a useful little book to help them

We hope you do indeed find this guide useful.
Remember, if you have
Remember, if you have any feedback to give – whether it be
positive or negative – then please contact a member of the any questions about this
Transformation Team. As an agile team ourselves, we are keen guide, or how agile
to inspect and adapt, and to improve things further!
practices will help
Why we’re “going agile”
improve your own way
To innovate effectively, we all need to be able to observe and
of working, then please
improve how we do things. This means doing work in small
increments rather than in a big planned way. We want the get in touch with the
opportunity to learn as we go along, to test our assumptions, Transformation Team.
and to make changes. That’s what agility is all about. We want
to deliver valuable increments frequently and to a robust level We’re here to help!
of quality.
An agile team does not try to identify requirements up-front,
and then go through a lengthy “waterfall” process whereby
value is added to in stages, and delivered too late.
Agility is about

innovation, and

reducing the leap-of-

faith needed before

results are seen.

3
Instead, we want to reduce leaps-of-faith as far as possible by
delivering value early and often. By working in an iterative Sprints and
and incremental way, we can evidence a better control of risk Increments
and get an earlier return on investment than we otherwise
would.
As you read through this guide, remember that each
“…remember that each
increment is delivered to a regular cadence known as a Sprint,
a time-boxed iteration of productivity. A Sprint must not increment is delivered to
exceed one month. That is the limit to the risk, the maximum
a regular cadence
leap‐of‐faith that ought to be taken.
known as a Sprint…”
A quick overview
In our agile way of working, Development Teams produce
increments of release quality at least once a month. During a Sprint, the
 A Product Owner orders work on a Product Backlog, and the team plan
Development Team will
to do some of it every iteration, known as a Sprint. The most important
items will be framed on a Sprint Backlog so an agreed Sprint Goal can work with a Product
be met. The Sprint Backlog is the team’s forecast of work for the Sprint.
 The team hold Daily Scrums to ensure they are on course to meet the Owner to deliver a
Goal. They update their Sprint Backlog forecast if needed.
 The team reserve time during the Sprint to help the PO refine Product valuable increment of
Backlog Items, so they can be planned into future Sprints.
work.
 The Sprint ends with a review of the increment and a retrospective of
the team’s way of working, including the quality of “Done” work.
 The Scrum Master removes impediments to the team’s progress.

By working iteratively, a

team can inspect and

adapt its progress and

improve the value it

delivers further.

4
ROLES
Who does what
There are 3 roles in an Agile Team. These are the Product
Owner, the Scrum Master, and the Development Team
themselves.

Product Owner “A Product Owner can be

The Product Owner (PO) represents thought of as a ‘value

stakeholder interests, including sponsors, maximizer…”

end‐customers, and indeed any users of the
system that is being delivered, increment‐ “The Scrum Master is a
upon-increment, by the developers. A PO can ‘servant-leader’…”
be thought of as a “value maximizer” who maintains the scope
of work on a Product Backlog and from which work is drawn “The Development Team,
each Sprint. for their part, are

Scrum Master professionals with all of

The Scrum Master is a “servant‐leader” for the skills needed…”

the team, someone who resolves
impediments to their progress, helps them to
retain a clear focus on the delivery of value
Each role has clear
each Sprint, and who coaches them towards
the best agile way of working. A Scrum duties & responsibilities.
Master is an expert in the application of agile
practice.

Development Team
The Development Team, for their part, are Remember that
professionals with all of the skills needed to
collaboration is essential
deliver those increments of value, fit for use
by those stakeholders represented by the PO. in agile practice.

The team will number between 3 and 9 developers…not so few

that any individual is likely to become a point of failure, and
not so many that communication and effective collaboration
between members is impeded.

5
ARTIFACTS
The Product
There are only three important artifacts in our agile way of
Backlog
working. These are the Product Backlog, the Sprint Backlog,
and the Increment. Remember that our focus is on delivering
value rather than on producing documents.

The Product Backlog “The Product Backlog

The Product Backlog captures the complete captures the complete

scope of work as it gradually emerges. It is scope of work as it

wholly owned by the Product Owner, who
gradually emerges…a
orders the work on it so the value delivered
by the team can be maximized. Each item good Product Backlog is
on the Product Backlog must have:
not a requirements
 a description
 an ordered position specification, but a tool
 a value to the Product Owner, and
for understanding…”
 an estimate.

Only the Development Team can decide

what the estimates should actually be, since
Product Backlog items
they are the ones who will do the work. The
team will provide these estimates to the Product Owner have a description,
during Product Backlog Refinement.
value, order & estimate.
A good Product Backlog is not a requirements specification,
but a tool for understanding requirements as they evolve, and
for communicating their meaning between the Product Owner
and the Development Team. A Product Backlog is never
frozen, but is constantly added to, tended, curated, and
At any given point, the
revised.
amount of work
 The backlog is ordered and work is drawn from it based on priority.
 As items are actioned, lower priority items will work their way up to the remaining on a Product
top of the backlog.
 Higher priority items are expressed in more detail than lower ones as Backlog can be summed.
they are expected to be brought into progress sooner.
 Product Backlog Refinement ensures that work is prepared in a timely
way for potential delivery in future sprints.

6
A key characteristic of a Product Backlog is that at any given
time, the amount of work remaining on it can be estimated Sprint Backlogs
and summed. The Product Owner can use this metric to re-
order the work and make delivery forecasts to the
stakeholders he or she represents.
“A Sprint Backlog is the
Our recommendation is to author Product Backlog Items in
the form of user stories. These explain the value being Development Team’s
provided to stakeholders, and are placeholders for
forecast of the work they
conversations between the Development Team and the
Product Owner about the work to be done. will do during a Sprint.”

The Sprint Backlog

A Sprint Backlog is the Development Team’s A Sprint Backlog is
forecast of the work they will do during a Sprint,
and their plan for achieving it. During Sprint never fixed, but is re-

Planning, the Development Team and the planned by the

Product Owner decide what work should be
Development Team so
selected from the Product Backlog to meet a good
Sprint Goal, and the team will plan how that work will be they can better meet the
done. They may do this by planning tasks for each user story.
Sprint Goal.
Once work is underway, the plan and forecast might need to
change so the Sprint Goal can be met. This is because the
team will learn more about the scope of work for the Sprint,
and what is needed to provide an increment of release quality,
as the Sprint progresses. The team will conduct a regular Daily
Scrum meeting to make sure that the Sprint Backlog is re-
planned and kept up-to-date. The Development Team
 The Sprint Backlog is not fixed during Sprint Planning, but changes so wholly own their Sprint
that the team can better meet the Sprint Goal.
 The team’s commitment ought to be the Sprint Goal, and not their Backlog, and no-one else
forecast of work on the Sprint Backlog. The forecast should change if
necessary in order to better meet the Goal. can add to or change the
 The Development Team wholly own their Sprint Backlog. No-one, not
even the Product Owner, can put work onto it without their say-so. work that is on it.

7
The Increment
Delivering
Every Sprint, the Development Team will produce
Increments
an increment of release quality which meets the
Sprint Goal, and which the Product Owner can
decide to make available to stakeholders. “Every Sprint, the

There’s nothing to stop an increment from being Development Team will

delivered as multiple smaller increments on an ongoing basis produce an increment of
throughout the Sprint. If this helps the Product Owner to
release quality which
maximize the value being delivered – and it often does – then
this is a good practice. meets the Sprint Goal,
 The rule is that no less than one increment ought to have been
and which the Product
provided by the end of the Sprint time-box. The continuous integration
and delivery of work is encouraged. Owner can decide to
 Remember, we are focused on providing value as early and often as
possible. make available to
 The team’s Definition of Done should be met for each increment, and
thereby ensure that each increment is of release quality. stakeholders.”

EVENTS
There are four events that occur within each Sprint, which is Incremental delivery
itself a time-boxed event that cannot exceed one month. These provides empirical
are Sprint Planning, the Daily Scrum, the Sprint Review, and
evidence of progress.
the Sprint Retrospective. Each event is time-boxed to a
certain length:
 Sprint Planning is time-boxed to 8 hours for a 1 month Sprint. This is
adjustable in ratio for shorter Sprint lengths. A planning session for a 2-
week Sprint would thus be time-boxed to 4 hours.
 The Daily Scrum is time-boxed to 15 minutes irrespective of how long a There are four events in
Sprint is.
 A Sprint Review is time-boxed to 4 hours for a 1 month Sprint, adjusted each Sprint. These are
in ratio for shorter Sprints.
 A Sprint Retrospective is time-boxed to 3 hours for a 1 month Sprint, Sprint Planning, the
and is also adjusted in ratio for shorter Sprints.
Daily Scrum, the Sprint

Review and the Sprint

Retrospective.

8
Sprint Planning
Sprint Planning
During Sprint Planning,
which cannot exceed 8 hours
for a 1 month Sprint, the team
plan the work they will do.
“The work the
 First, they select which items from
the Product Backlog they will Development Team
implement that Sprint. This selection
plans onto the Sprint
will allow a Sprint Goal to be met
which they agree with the Product
Backlog should be
Owner
 The Development Team will then sufficient to produce an
plan the technical work (tasks) they
believe they will need to accomplish increment which meets
in order to meet the Sprint Goal.
the Goal and which is of
The resulting Sprint Backlog is the Development Team’s
release quality.”
forecast of the work they must do to meet the Sprint Goal they
agree with the Product Owner.
 No‐one can force work onto the Development Team.
 They produce their own plan of work for that reasonable and achievable Sprint Planning gives
agreed Goal, a forecast of what they will do in order to achieve it. This
plan is known as the Sprint Backlog and it will encompass the technical the team a forecast of
activities, such as tasks, which the Development Team expect they
work to meet the Sprint
must complete.
 The Development Team own their Sprint Backlog. It is their forecast of Goal.
what they must do to meet the Sprint Goal, and it is theirs to re-plan as
necessary.
 The work the Development Team plans onto the Sprint Backlog should
be sufficient to produce an increment which meets the Goal and which
A Sprint Goal should be
is of release quality.
achievable and give
The Sprint Goal
coherence to the Product
During Sprint Planning, the Development Team and the
Product Owner frame an achievable and useful Sprint Goal. Backlog Items selected
This goal, when satisfied by the delivery of the increment, will
for the Sprint, and to the
resolve the leap‐of‐faith for the Sprint.
increment delivered.
A good Sprint Goal gives coherence to the Product Backlog
items chosen for the Sprint, and makes a release valuable.

9
The Sprint
Sprints
A Sprint is an iteration, a
period of work time-boxed
“During the Sprint, the
to a maximum of one
month. Sprints should be team performs the work
kept to a consistent length
they have planned into
so that the team can
forecast work, and inspect their Sprint Backlog.
and adapt their progress,
They craft an increment
with the best accuracy possible. A good Sprint length will
balance the needs of the Product Owner with the ability of the that will meet the Sprint
team to plan a good Sprint Goal, and to inspect and adapt Goal, and to the level of
their progress towards it.
quality that is stipulated
During the Sprint, the team performs the work they have
planned into their Sprint Backlog. in the Definition of

 They craft an increment that will meet the Sprint Goal, and to the level Done.”
of quality that is stipulated in the Definition of Done.
 They hold regular Daily Scrums, and re-plan their Sprint Backlog if
necessary so as to better meet the Sprint Goal.
 The team will also work with the Product Owner to further refine the A Sprint is a time-box for
Product Backlog.
producing increments of
The Definition of Done
value.
The level of quality needed
to assure the release of a
truly usable increment is
expressed as the Definition
of Done. This definition
The Definition of Done
will stipulate the
characteristics of an asserts the level of
increment which is genuinely fit for purpose…the
quality that must be built
environment in which it must be supported, its performance
levels, the testing that is required, any documentation that into each increment for
must be produced, and perhaps a host of other considerations. release.
It is important to be clear about what “Done” means if
unnecessary rework and waste is to be avoided.

10
Product Backlog Refinement
A Product Backlog is Inspect & Adapt
constantly evolving. Order
and detail will be added, and “A Product Backlog is
the Development Team will constantly evolving.
provide estimates for each
Order and detail will be
item. They will ensure that the scope of the
proposed work is understood sufficiently well so added, and the
that future Sprint Planning sessions can occur
Development Team will
without impediment, and so that the amount of
work that is thought to be remaining can be provide estimates…they
measured. The team should reserve enough time during a
will hold a 15-minute
Sprint to refine the backlog in a timely manner.
Daily Scrum…at the end
The Daily Scrum
of the Sprint a Review
Every working day, the Development Team
will be held…a
will hold a 15‐minute Daily Scrum. This is
an opportunity for the team to inspect and Retrospective will also
adapt their progress towards the Sprint be conducted”
Goal, and to re-plan their forecast of work – the Sprint
Backlog – if necessary. Team members will clarify what they
have done so far and what they plan to do next. The focus is
on completing work already in progress. If anything is causing Timely feedback of this
an obstruction, the Scrum Master will take the impediment in nature enables agility.
hand and resolve it.

The Sprint Review

Remember that each
At the end of each Sprint a Review will be
held. The focus is on the product, including event in Scrum is an
the work done and any work which still
opportunity for the team
remains to be done. A demonstration may be
a key part of this event, which is time-boxed to inspect and adapt
to a maximum of 4 hours for a 1 month Sprint. The Product something.
Owner may invite interested stakeholders to see what is being
delivered. Any work that was not done will also be reviewed,
re-estimated and re‐ordered on the Product Backlog.
11
The Sprint Retrospective
Metrics
A Retrospective will also be conducted at
the end of each Sprint. Whereas the Sprint
“…the Retrospective is
Review is focused on the product being
delivered, the Retrospective is concerned concerned with the
with the process being followed, and how
process being followed,
it might be improved. The maximum time-
box for this event is 3 hours for a 1 month Sprint. The Product and how it might be
Owner, Scrum Master, and Development Team must all
improved… the team
attend. It is their responsibility, as agile professionals, to find
ways to improve their implementation of Scrum and the level may look for things that
of quality which the Definition of Done observes. went well and did not go
 All team members must attend, including the Product Owner and the
well, and agree ideas for
Scrum Master. No-one else should attend so the team can express
opinions freely and confidentially.
improvement. They may
 Everyone must provide input, and must have an equal say
 There must be openness and mutual respect – this is a pre-condition to examine their metrics”
holding a retrospective
 The team may look for things that went well and did not go well, and
agree ideas for improvement. They may examine their metrics.
 There should be clear actions following each Retrospective Metrics provide objective

METRICS & quantifiable evidence

of team performance.
If a team is to improve its process, then the availability of
metrics will prove useful. Metrics are an objective measure of
how the team is performing. The metrics which are of most
use to agile teams are:
 Product burn rates, i.e. the rate at which work is being consumed and
implemented from the Product Backlog. Remember that the amount of Useful metrics include
work remaining on a Product Backlog (as estimated by the
Development Team) should be quantifiable at any point. evidence of product and
 Sprint burn rates, i.e. the rate at which the team complete the tasks that
sprint burn rates, and
they have planned onto their Sprint Backlog.
 Velocity, which is the amount of work completed in the Sprint as per the the team’s throughput or
total size of items implemented.
 Throughput, which is the number of Product Backlog items velocity.
implemented in the Sprint.

12
There are essentially two sorts of burn rate: the Product
Burndown and the Sprint Burndown. Both provide useful Burn rates
metrics for consideration in a Sprint Retrospective.
600 “There are essentially
500
two types of burndown:
400
Story Points

300 Product Burndown and

200
100 Sprint Burndown. Both
0
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 provide useful metrics

A Product Burndown shows the rate at which work is being for consideration in a
completed from the Product Backlog.
Sprint Retrospective”
 Sprints are articulated on the x-axis and the amount of work remaining
on the y-axis.
 Remember that at any given time, the amount of estimated work
remaining in the Product Backlog can be summed. A Product Owner
Burn rates provide an
can use this to appraise stakeholders of likely release dates.
 Each item may be relatively sized in terms of “points”. These are the indication of likely
Development Team’s estimates, and represent the complexity and
effort they believe to be involved. completion times and

1200 allow forecasts to be

1000 made or revised.

Estimated Task Hours

800

600

400

200
Velocity is the amount of
0
Day of Sprint
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 work completed in a
A Sprint Burndown shows the rate at which the Development
Sprint. This can help a
Team completes the work which they have planned into their
Sprint Backlog. team budget for how

 At any time, the work remaining in the Sprint Backlog can be summed. much work they can take
 By tracking the remaining work throughout the Sprint, the Development
Team can manage its progress. on in Sprint Planning.
 Sudden drop-offs may indicate bottlenecks.

13
USER STORIES AND THEIR ACCEPTANCE CRITERIA
Evolving
A user story is a placeholder for a conversation about a
requirements
requirement. In agile practice, we don’t define requirements
up front. We let them evolve along with our understanding of
“A user story is a
what’s needed. That’s why user stories have proven so
popular. placeholder for a
A user story is typically captured in the following format: conversation about a
"As a <role>, I need/want <goal/desire> so that requirement”
<benefit>".
The goals and benefits can be broken into clauses, each of
which is joined by "and". Here’s an example:
Requirements are
As a user closing the application, I want to be
fleshed out in greater
prompted to save anything that has changed since the
last save so that I can preserve useful work and discard detail the closer they get
erroneous work.
to the point of being
A common mistake is to construct a User Story as a tautology.
worked on. This is the
For example, the above story might be miswritten in the
following way: “As a user closing the application, I want to be purpose behind Product
prompted to save anything that has changed since the last
Backlog Refinement.
save so that anything since the last change is saved”. Instead
we should write it in such a way that the benefit is clearly
separated from the goal.
A User Story should give a clear expression of the business
value, including who expects it and why.
 Card. The story should be concise enough to write on a simple index
card along with any annotations that may be required. If acceptance criteria are
 Conversation. The story is discussed and clarified, re-estimated if
necessary, and perhaps even re-written. The benefit is an improved well understood, a
understanding at the point of development, and deliveries that are
consistently fit for purpose. Development Team will
 Confirmation. A shared understanding of the User Story is confirmed
be able to make
by the delivery of work products that meet the requirement.
informed estimates.
To be confirmable and testable, every User Story should have
sufficient, well-formed acceptance criteria to assert its quality.

14
Like User Stories, Acceptance Criteria are brief sentences that
conform to a certain format. The difference is that they place Acceptance
the focus not on statements of value but on tangible outputs: Criteria
"Given <initial context>, when/where <event or
condition>, then <expected outcome>" “…Acceptance

Here’s an example of one possible Acceptance Criterion for Criteria…place the focus
the User Story we saw earlier:
not on statements of
Given that a running application has open work, when
value but on tangible
the application is closed and changes to the work have
been made since the last save, then the user will be outputs”
prompted to save the work.
A common mistake made by teams is to write Acceptance
Criteria that simply rephrase the User Story, and thereby lack When teams estimate
focus on tangible outputs. Here’s an example of how the above
work, they pay close
criterion might have been miswritten:
attention to the
“Given that a user is closing the application, when they
are prompted to save anything that has changed since acceptance criteria that
the last save then the system will preserve useful work
must be met.
and discard erroneous work”.
This is a restatement of value rather than a test of specific
circumstance that would be required for objectivity.
The better written a User Story, the more effectively the “3
C’s” will be enabled. A good story meets the INVEST criteria:
 Independent. User Stories should not overlap in terms of the value
they deliver.
 Negotiable. It should be possible to debate and change User Stories,
and to trade them in and out of scope. There will usually be
 Valuable. Every User Story must deliver stakeholder benefit.
 Estimable. It should be possible to anticipate how much effort a User multiple acceptance
Story will require for implementation.
criteria for each user
 Small. It is better to work on multiple small pieces of work than a larger
one, since progress is more easily ascertained and at least some value story.
can potentially be delivered earlier.
 Testable. It should be possible to confirm the successful completion of
a User Story by objective means.

15
ESTIMATION TECHNIQUES
Estimation can only be done by Development Team members, Estimation
since they will be the ones doing the work.
Planning Poker uses cards with the following numbers: ½ 1 ” Estimation can only be
2 3 5 8 13 20 40 100. Here's how it's played:
done by Development
 An identical hand of cards is given to each team member. Each team
member will have a set of cards with numbers on the above scale. Team members, since
 The Product Owner describes the piece of work to be estimated.
they will be the ones
Normally this is a user story with acceptance criteria.
 Each team member mentally estimates the size of it on the scale. They doing the work”
can ask the Product Owner questions to clarify any points, but for the
moment they will keep their estimate to themselves.
 Each team member places the card that corresponds to their mental
estimate face down in front of them.
Planning Poker or T-
 At the facilitators instruction - usually the Scrum Master - the team turn
their cards over. In an ideal case the cards will all have the same value, Shirt Sizing may be
suggesting that the team have a common understanding of the
requirements and the likely effort that will be involved. used.
 If the values are different, the team then need to discuss their estimates
and their reasoning behind them. They need to understand each other’s T-shirt sizes may be
thinking, and from that reach a consensus. It may be necessary to
replay the cards several times before agreement is reached. mapped to a story point
 Estimates may be recorded on the story & then put on a Scrum board.
schedule so burn rates
T-Shirt Sizing All you need are six scraps of paper and a set
can be tracked.
of index cards with the requirements (e.g. user stories) written
on them. Normally these will be the same index cards that go
on the Scrum board.
 Write one of the following sizes on each of the scraps of paper: Extra T Shirt Suggested
Small (XS), Small (S), Medium (M), Large (L), Extra Large (XL), and Size Point Value
Extra Extra Large (XXL)
XS 1
 Arrange the sizes in a horizontal line on a table, ordered from XS on the
left to XXL on the right. S 2
 Put the pile of index cards on the table in front of the sizing line.
M 3
 The team then collaborate to organise the requirements on the cards
under the headings XS to XXL. They can ask the Product Owner to L 5
clarify any questions that they may have while doing so.
 Once the cards have all been sorted, story points can be allocated to XL 8
each of them by mapping each T-Shirt size to a value. This allows
XXL 13
metrics to be gathered about the flow of work, and used to populate a
velocity or burndown chart.

16
 Boards
INFORMATION RADIATORS
Agile practice sits on the three legs of transparency, ” A good information
inspection, and adaptation. Agile teams should therefore
radiator will show
make good use of information radiators so they have good
visibility of the work being done, and can inspect and adapt timely information to the
accordingly. A good
people who need it when
information radiator
will show timely they need it…the most
information to the common type of
people who need it
when they need it, information radiator is a
and thereby render Scrum Task Board”
the production of
reports unnecessary.
The most common
type of information A useful board will show

radiator is a Scrum the state of progress and

Task Board.
allow easy inspection
 This shows the work that the team have planned into their Sprint
Backlog and its progress towards completion during the Sprint itself. and adaptation of the
 It’s a good idea for a team to conduct their Daily Scrum in front of a
board such as this, so they can re-plan their work easily. team’s plan.
 Boards can be physical or electronic. Teams should come up with a
scheme for showing any blockages to their workflow. They should also
look for work building up in any particular area, as this can indicate
inefficiencies. Remember, it’s a good

A Task Board will show the progress of work as it moves from idea for a team to hold
the backlog through to Done.
their Daily Scrum in
 An elementary board will have a Backlog, In Progress, and Done
stations. front of an up-to-date
 A more advanced one will show additional stations which show where
task board.
work is building up.
 A useful agile team member will be sufficiently cross-trained to act on
this information and ease any blockages before bringing any new work
out of the backlog.

17