1
00:00:06,720 --> 00:00:09,090
- To keep the product backlog healthy,

2
00:00:09,090 --> 00:00:12,333
the team needs to continuously refine it.

3
00:00:13,170 --> 00:00:16,440
Backlog refinement is
when the product owner

4
00:00:16,440 --> 00:00:18,840
and some, or all, of the rest of the team

5
00:00:18,840 --> 00:00:22,020
review items on the backlog

6
00:00:22,020 --> 00:00:23,850
to ensure that the backlog contains

7
00:00:23,850 --> 00:00:26,403
the appropriate specifications.

8
00:00:27,600 --> 00:00:29,790
They need to make sure
that those requirements

9
00:00:29,790 --> 00:00:32,580
are prioritized, the
right items on the top

10
00:00:32,580 --> 00:00:36,090
of the backlog and are ready for delivery.

11
00:00:36,090 --> 00:00:38,460
This activity occurs on a regular basis

12
00:00:38,460 --> 00:00:40,710
and may beneficial the scheduled meeting

13
00:00:40,710 --> 00:00:43,260
or an ongoing activity.

14
00:00:43,260 --> 00:00:45,810
The overall intent of backlog refinement

15
00:00:45,810 --> 00:00:49,200
is to ensure that the
backlog remains populated

16
00:00:49,200 --> 00:00:52,800
with items that are relevant,
detailed, and estimated

17
00:00:52,800 --> 00:00:55,440
to a degree appropriate
with their priority.

18
00:00:55,440 --> 00:00:59,250
And also, it's important to
keep the backlog up to date,

19
00:00:59,250 --> 00:01:01,950
meaning in line with the
current understanding

20
00:01:01,950 --> 00:01:05,640
of the project or product
and its objectives.

21
00:01:05,640 --> 00:01:08,640
Some of the activities that
happened during the refinement,

22
00:01:08,640 --> 00:01:11,010
include, first, removing user stories

23
00:01:11,010 --> 00:01:13,110
that no longer relevant,

24
00:01:13,110 --> 00:01:15,030
second, creating new user stories

25
00:01:15,030 --> 00:01:17,820
in response to the newly discovered needs,

26
00:01:17,820 --> 00:01:20,640
re-assessing the relative
priority of stories,

27
00:01:20,640 --> 00:01:22,470
assigning estimates to stories

28
00:01:22,470 --> 00:01:24,480
on the top of the backlog,

29
00:01:24,480 --> 00:01:26,520
correcting any estimates in light

30
00:01:26,520 --> 00:01:29,490
of the newly discovered information,

31
00:01:29,490 --> 00:01:31,860
and finally, splitting user stories

32
00:01:31,860 --> 00:01:33,630
or decomposing user stories

33
00:01:33,630 --> 00:01:36,390
that are high priority but too significant

34
00:01:36,390 --> 00:01:39,570
in effort to feed the upcoming Sprint.

35
00:01:39,570 --> 00:01:41,220
Product backlog refinement

36
00:01:41,220 --> 00:01:44,550
usually was called backlog grooming.

37
00:01:44,550 --> 00:01:48,210
The earliest recorded use
of the term backlog grooming

38
00:01:48,210 --> 00:01:50,370
is from Mike Cohn, who is the guru

39
00:01:50,370 --> 00:01:52,230
of agile requirements management,

40
00:01:52,230 --> 00:01:56,010
and he started using it in 2005.

41
00:01:56,010 --> 00:01:58,080
Grooming was originally used to reflect

42
00:01:58,080 --> 00:02:02,040
on organic approach to
product backlog maintenance.

43
00:02:02,040 --> 00:02:05,940
And the use of the word grooming

44
00:02:05,940 --> 00:02:09,150
had some negative
connotations in some cultures.

45
00:02:09,150 --> 00:02:12,390
So this specific activity has been renamed

46
00:02:12,390 --> 00:02:14,220
to backlog refinement,

47
00:02:14,220 --> 00:02:17,220
but many practitioners
still use the word grooming.

48
00:02:17,220 --> 00:02:18,720
If you hear backlog grooming,

49
00:02:18,720 --> 00:02:21,693
it is a synonym to backlog refinement.

50
00:02:22,800 --> 00:02:24,960
There are overall different practices

51
00:02:24,960 --> 00:02:27,630
in terms of frequency of
product backlog refinement

52
00:02:27,630 --> 00:02:30,150
and ownership of this event.

53
00:02:30,150 --> 00:02:33,390
This practices differ
between organizations.

54
00:02:33,390 --> 00:02:35,550
Some teams schedule refinement sessions

55
00:02:35,550 --> 00:02:37,680
as part of the Sprint cadence

56
00:02:37,680 --> 00:02:41,220
and have all team members
participate in those sessions,

57
00:02:41,220 --> 00:02:43,680
discuss user stories, align on estimates

58
00:02:43,680 --> 00:02:47,160
and take action items to
find the missing details.

59
00:02:47,160 --> 00:02:49,380
In some other organizations,

60
00:02:49,380 --> 00:02:52,110
the ownership is with the product manager

61
00:02:52,110 --> 00:02:55,110
and product manager will make decisions

62
00:02:55,110 --> 00:02:57,690
upon consulting with the
relevant stakeholders

63
00:02:57,690 --> 00:03:00,540
and make their backlogs
available to team members

64
00:03:00,540 --> 00:03:02,160
for review and feedback.

65
00:03:02,160 --> 00:03:04,710
And product manager
could be the same person

66
00:03:04,710 --> 00:03:08,130
as the product owner or
could be a separate person

67
00:03:08,130 --> 00:03:09,630
for a large products,

68
00:03:09,630 --> 00:03:12,750
where there are several
sub-products involved

69
00:03:12,750 --> 00:03:15,120
that needs coordination and alignment

70
00:03:15,120 --> 00:03:17,340
in terms of decision making.

71
00:03:17,340 --> 00:03:20,100
Overall in my experience,
the more collaborative

72
00:03:20,100 --> 00:03:22,290
and structured the approach is,

73
00:03:22,290 --> 00:03:24,090
the more well defined it is,

74
00:03:24,090 --> 00:03:26,640
the less room is there for scope creep.

75
00:03:26,640 --> 00:03:28,080
For any misunderstanding,

76
00:03:28,080 --> 00:03:30,870
any confusion, any change in scope.

77
00:03:30,870 --> 00:03:33,783
Overall, there are several
principles to follow.

78
00:03:34,740 --> 00:03:37,680
Number one, product backlog refinement

79
00:03:37,680 --> 00:03:40,500
is not limited to the refinement session.

80
00:03:40,500 --> 00:03:43,200
The product owner has to set clear vision

81
00:03:43,200 --> 00:03:45,030
communicated to the team,

82
00:03:45,030 --> 00:03:46,500
aligned with the stakeholders

83
00:03:46,500 --> 00:03:50,070
and continuously remind
them what is the true north.

84
00:03:50,070 --> 00:03:52,503
What is the objective
they want to achieve?

85
00:03:53,550 --> 00:03:58,110
The second is that product
owner is in constant contact

86
00:03:58,110 --> 00:04:02,490
with the business and also
the technology stakeholders.

87
00:04:02,490 --> 00:04:04,530
This means that there are no surprises

88
00:04:04,530 --> 00:04:08,280
that specific user stories
are getting deprioritized

89
00:04:08,280 --> 00:04:10,980
and a business stakeholder
is upset about it

90
00:04:10,980 --> 00:04:12,870
because they need this functionality.

91
00:04:12,870 --> 00:04:15,600
And some of those are not
included in the backlog

92
00:04:15,600 --> 00:04:18,510
and that's even worse
misalignment situation.

93
00:04:18,510 --> 00:04:21,630
So overall I do not suggest deleting ever

94
00:04:21,630 --> 00:04:24,180
any user stories that
you have on your backlog.

95
00:04:24,180 --> 00:04:27,180
If they're no longer needed, cancel them,

96
00:04:27,180 --> 00:04:31,410
and put in comments why
you have chosen to do so

97
00:04:31,410 --> 00:04:34,290
and let's keep them there for the record.

98
00:04:34,290 --> 00:04:37,380
The third principle is that the workload

99
00:04:37,380 --> 00:04:38,790
for the backlog elements

100
00:04:38,790 --> 00:04:42,000
has to be very well-defined
and communicated.

101
00:04:42,000 --> 00:04:44,160
This includes your intake mechanism,

102
00:04:44,160 --> 00:04:47,400
any categories, any expected format,

103
00:04:47,400 --> 00:04:49,470
approvals, and so forth.

104
00:04:49,470 --> 00:04:53,730
Usually it is done off the
working agreement of the team.

105
00:04:53,730 --> 00:04:55,950
In the working agreement, the team defines

106
00:04:55,950 --> 00:04:58,470
the rule and practices and behaviors

107
00:04:58,470 --> 00:05:01,050
how they want to work together,

108
00:05:01,050 --> 00:05:03,840
and putting your intake
and decision making

109
00:05:03,840 --> 00:05:06,210
for your backlog in the working agreement

110
00:05:06,210 --> 00:05:07,803
is usually a good idea.

111
00:05:08,760 --> 00:05:13,760
And remember, if a requirement
is not in the backlog,

112
00:05:14,190 --> 00:05:16,560
it does not exist.

113
00:05:16,560 --> 00:05:20,820
Always resists the anti-pattern
of doing work of the books

114
00:05:20,820 --> 00:05:23,970
even if can be absorbed
within the current Sprint

115
00:05:23,970 --> 00:05:27,063
and even if it is the right
thing to do for your product,

116
00:05:27,900 --> 00:05:29,520
put it in the product backlog.

117
00:05:29,520 --> 00:05:33,390
Your backlog is the
documentation for your product.

118
00:05:33,390 --> 00:05:38,190
So if any undocumented work
will go into production,

119
00:05:38,190 --> 00:05:40,410
it'll create issues with extending

120
00:05:40,410 --> 00:05:44,220
or removing any related
functionality in the future.

121
00:05:44,220 --> 00:05:46,320
So remember the mantra,

122
00:05:46,320 --> 00:05:49,653
if it is not in the
backlog, it does not exist.