[SCRUMDEVELOPMENT] Backlog Refinement as an Event Between Two Sprints

[[e-mail] [SCRUMDEVELOPMENT]]

I just voted for the idea 'Include Backlog Refinement in the Scrum Events section' in Scrumguide.uservoice.com, proposed by Jose Luis Soria (http://scrumguide.uservoice.com/users/47440411-jose-luis-soria)

http://t.co/9HeoLDjyel http://t.co/9HeoLDjyel

There I have expressed my opinion as follows:
"I agree with this idea.
Though planning is an ongoing activity & yet we have events like time-boxed Scrum Planning.
Similarly backlog refinement is ongoing as an individual activity of the PO but still we need to have it additionally as an event with the entire team participation.
In fact I will go beyond this and suggest that this be scheduled as a time-boxed event (10 % of the Sprint duration) immediately after sprint retrospective and just before the next Sprint planning session of the next sprint. Scheduling backlog refinement meeting as an event during a sprint will shift the team member focus from the current sprint to the forthcoming sprint. This will be a case of context switching which has been regarded as a waste from Lean perspective.
But if a time-boxed backlog grooming is scheduled between two sprints the team can give full focus. So a typical 2-week sprint schedule will look like
Monday -First Half : Sprint Planning and
then after two weeks
Friday - First Half: Sprint Review and Sprint Retrospective
Friday - Second Half - Backlog refinement
Monday - First Half - Sprint Planning (next sprint) One limitation with this approach is if the PO is not available on the Backlog Refinement Event is scheduled then it will get adversely impacted. But the same can be said of scheduled Sprint Planning session too."


Welcome your opinions.


- Gopinath

[Dinesh Sharma [e-mail] [SCRUMDEVELOPMENT]]

Gopinath
Backlog refinement is not one off meeting during sprint. So for a 2 week spring I advice to have four 1hr refinement sessions during a sprint. That way not only it allows POs to speak with users/stakeholders when they don't have answers about user stories being discussed but also it allows team to go and check any technical discussions they need to have for feasibility of story implementation. That's what has pretty much worked for all my teams that I have coached. Happy to hear don't different approaches people has used on this topic.


Dinesh


Sent from my iPhone

Post by ***@yahoo.com [SCRUMDEVELOPMENT]
I just voted for the idea 'Include Backlog Refinement in the Scrum Events section' in Scrumguide.uservoice.com, proposed by Jose Luis Soria (http://scrumguide.uservoice.com/users/47440411-jose-luis-soria)
http://t.co/9HeoLDjyel
"I agree with this idea.
Though planning is an ongoing activity & yet we have events like time-boxed Scrum Planning.
Similarly backlog refinement is ongoing as an individual activity of the PO but still we need to have it additionally as an event with the entire team participation.
In fact I will go beyond this and suggest that this be scheduled as a time-boxed event (10 % of the Sprint duration) immediately after sprint retrospective and just before the next Sprint planning session of the next sprint. Scheduling backlog refinement meeting as an event during a sprint will shift the team member focus from the current sprint to the forthcoming sprint. This will be a case of context switching which has been regarded as a waste from Lean perspective.
But if a time-boxed backlog grooming is scheduled between two sprints the team can give full focus. So a typical 2-week sprint schedule will look like
Monday -First Half : Sprint Planning and
then after two weeks
Friday - First Half: Sprint Review and Sprint Retrospective
Friday - Second Half - Backlog refinement
Monday - First Half - Sprint Planning (next sprint)
One limitation with this approach is if the PO is not available on the Backlog Refinement Event is scheduled then it will get adversely impacted. But the same can be said of scheduled Sprint Planning session too."
Welcome your opinions.
- Gopinath

[[e-mail] [SCRUMDEVELOPMENT]]

Dinesh,

I fully agree with what you say. In fact it has been my approach too.
But I have also observed having several backlog grooming sessions with the team during a sprint distracts them from the work they are doing for the current sprint. In the backlog grooming meeting they are preoccupied to effectively participate (though this may not be the case with experienced teams).
And then when they go back to the work after the backlog grooming meetings they have to switch the context. This I think is somewhat does not gel well with the Scrum Value - Focus.
So if we hold the Backlog grooming session between two sprints there will be more focus on this event.
The finding out answers about user stories and technical discussion regarding can always happen outside the backlog grooming meeting.
Finally it is all context dependent.We need to choose what works well for us.

Gopinath

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

In our teams, we have had success in putting a grooming meeting mid
sprint. If you put it at the end/beginning, you're essentially making a
marathon planning meeting, which is one of the things we tried to avoid by
using the grooming meeting. It's also nice to have an all team meeting
that doesn't have the "get it planned before we start" pressure of the
planning meeting or has a higher level context than specific individual
stories that are on people's mind day to day during the sprint. In fact,
in my experience, the best design discussion have happened in this context
because it's a time to think completely free-form about any future
stories. I feel that we had much more creative flow this way.


-Cass

Post by ***@yahoo.com [SCRUMDEVELOPMENT]
Dinesh,
I fully agree with what you say. In fact it has been my approach too.
But I have also observed having several backlog grooming sessions with the
team during a sprint distracts them from the work they are doing for the
current sprint. In the backlog grooming meeting they are preoccupied to
effectively participate (though this may not be the case with experienced
teams).
And then when they go back to the work after the backlog grooming meetings
they have to switch the context. This I think is somewhat does not gel well
with the Scrum Value - Focus.
So if we hold the Backlog grooming session between two sprints there will
be more focus on this event.
The finding out answers about user stories and technical discussion
regarding can always happen outside the backlog grooming meeting.
Finally it is all context dependent.We need to choose what works well for us.
Gopinath

[[e-mail] [SCRUMDEVELOPMENT]]

Have to agree with you Cass, mid sprint works well.

G.

[Charles Bradley - Professional Scrum Trainer and Coach [e-mail] [SCRUMDEVELOPMENT]]

+1 for Mid sprint grooming, which coincides with my Tip#1 from my 18 tips on Backlog Refinement.
And back to the current topic, I've voted against including refinement as an event on uservoice.

<snip>

Tip #1: Try to never schedule backlog refinement during the first or last 20% of the Sprint.
During the first 20% of the Sprint, the team is just getting started on this Sprint's work, so you'll want to give them some room to get a good start. During the last 20% of the Sprint, the team is working hard to get closure on the current sprint items, so that's not really an ideal time to do it either. That middle 60% of the sprint is a good time to do backlog refinement.</snip> -------
Charles Bradley
Professional Scrum Trainer
Scrum Coach-in-Chief
http://ScrumCrazy.com


From: "***@yahoo.co.uk [SCRUMDEVELOPMENT]" <***@yahoogroups.com>
To: ***@yahoogroups.com
Sent: Friday, February 20, 2015 9:32 AM
Subject: [SCRUMDEVELOPMENT] Re: Backlog Refinement as an Event Between Two Sprints

#yiv4736033297 #yiv4736033297 -- #yiv4736033297 .yiv4736033297ygrp-photo-title{clear:both;font-size:smaller;height:15px;overflow:hidden;text-align:center;width:75px;}#yiv4736033297 div.yiv4736033297ygrp-photo{background-position:center;background-repeat:no-repeat;background-color:white;border:1px solid black;height:62px;width:62px;}#yiv4736033297 div.yiv4736033297photo-title a, #yiv4736033297 div.yiv4736033297photo-title a:active, #yiv4736033297 div.yiv4736033297photo-title a:hover, #yiv4736033297 div.yiv4736033297photo-title a:visited {text-decoration:none;}#yiv4736033297 div.yiv4736033297attach-table div.yiv4736033297attach-row {clear:both;}#yiv4736033297 div.yiv4736033297attach-table div.yiv4736033297attach-row div {float:left;}#yiv4736033297 p {clear:both;padding:15px 0 3px 0;overflow:hidden;}#yiv4736033297 div.yiv4736033297ygrp-file {width:30px;}#yiv4736033297 div.yiv4736033297attach-table div.yiv4736033297attach-row div div a {text-decoration:none;}#yiv4736033297 div.yiv4736033297attach-table div.yiv4736033297attach-row div div span {font-weight:normal;}#yiv4736033297 div.yiv4736033297ygrp-file-title {font-weight:bold;}#yiv4736033297 #yiv4736033297 #yiv4736033297 #yiv4736033297 --#yiv4736033297ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;margin:10px 0;padding:0 10px;}#yiv4736033297 #yiv4736033297ygrp-mkp hr {border:1px solid #d8d8d8;}#yiv4736033297 #yiv4736033297ygrp-mkp #yiv4736033297hd {color:#628c2a;font-size:85%;font-weight:700;line-height:122%;margin:10px 0;}#yiv4736033297 #yiv4736033297ygrp-mkp #yiv4736033297ads {margin-bottom:10px;}#yiv4736033297 #yiv4736033297ygrp-mkp .yiv4736033297ad {padding:0 0;}#yiv4736033297 #yiv4736033297ygrp-mkp .yiv4736033297ad p {margin:0;}#yiv4736033297 #yiv4736033297ygrp-mkp .yiv4736033297ad a {color:#0000ff;text-decoration:none;}#yiv4736033297

Have to agree with you Cass, mid sprint works well.
G.

[Wouter Lagerweij [e-mail] [SCRUMDEVELOPMENT]]

I don't understand these proposals...

I see backlog refinement as a continuous process. I do have a full-team
session as part of that process (usually), but also many three-amigo's
sessions, or just impromptu discussions. To me, the proposal makes as much
sense as suggesting placing the development and test work for the sprint
into meetings.

Wouter

Post by ***@yahoo.com [SCRUMDEVELOPMENT]
I just voted for the idea 'Include Backlog Refinement in the Scrum Events
section' in Scrumguide.uservoice.com, proposed by Jose Luis Soria (
http://scrumguide.uservoice.com/users/47440411-jose-luis-soria)
http://t.co/9HeoLDjyel
"I agree with this idea.
Though planning is an ongoing activity & yet we have events like time-boxed Scrum Planning.
Similarly backlog refinement is ongoing as an individual activity of the
PO but still we need to have it additionally as an event with the entire
team participation.
In fact I will go beyond this and suggest that this be scheduled as a
time-boxed event (10 % of the Sprint duration) immediately after sprint
retrospective and just before the next Sprint planning session of the next
sprint. Scheduling backlog refinement meeting as an event during a sprint
will shift the team member focus from the current sprint to the forthcoming
sprint. This will be a case of context switching which has been regarded as
a waste from Lean perspective.
But if a time-boxed backlog grooming is scheduled between two sprints the
team can give full focus. So a typical 2-week sprint schedule will look
like
Monday -First Half : Sprint Planning and
then after two weeks
Friday - First Half: Sprint Review and Sprint Retrospective
Friday - Second Half - Backlog refinement
Monday - First Half - Sprint Planning (next sprint)
One limitation with this approach is if the PO is not available on the
Backlog Refinement Event is scheduled then it will get adversely impacted.
But the same can be said of scheduled Sprint Planning session too."
Welcome your opinions.
- Gopinath

[Ron Jeffries [e-mail] [SCRUMDEVELOPMENT]]

H Wouter,

I see backlog refinement as a continuous process. I do have a full-team session as part of that process (usually), but also many three-amigo's sessions, or just impromptu discussions. To me, the proposal makes as much sense as suggesting placing the development and test work for the sprint into meetings.

Less, in fact. The thing is this:

The whole notion of backlog refinement is that it requires multiple skills to refine a backlog item. The three amigos notion you raise reflects this, suggesting that a business-focused person, a developer, and a tester should come together to flesh out a story. In general, there are a few different skills and understandings needed to really do a good job refining a story, and unless the team members are quite broad in skills, different people will be the right ones to contribute to different items.

We do not want everyone tied up: there is no need, and it’s wasteful. We do not want the same people tied up all the time: diversity is good and we benefit from cross-fertilization of ideas.

Finally, each item’s elaboration needs to happen at a different time and different pace. Just as we don’t work on developing all items at once, but have the whole team or the right subset work on one at a time, elaborating the items wants to happen more or less one at a time, or in small related batches, when the Product Owner is ready to work on them.

Rather than an all-hands meeting, or, worse, a meeting from which people are excluded, what seems to work best is for the Product Owner to pop in, account that she has a few stories about topic X to work on, and gather up a few people who are interested, over the course of the Sprint.

Just as it takes a whole Sprint to develop the Sprint backlog items, it takes a whole Sprint to refine the next ones: it just doesn’t require such a large team.

That’s why Backlog Refinement is not a meeting, and why making it one reduces effectiveness rather than increasing it. It’s an apparent efficiency that loses effectiveness.

Ron Jeffries
ronjeffries.com <http://ronjeffries.com/>
Impossible is not a fact. It is an opinion. -- Muhammad Ali

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

I understand your aversion, and I agree logically with all the details of
your argument. But I have seen wonderfully creative discussion occur in
our teams because we took a couple of hours to stop the current rat race of
the sprint to sit and just talk about the future of the product. The most
creative design discussions happen at this evil meeting. It could just be
the dynamics of our teams or the fact that most of our teams are still new
to the idea of agile. But your logical dissection of the concept cannot
undue the joy I felt week after week watching the teams spread their wings
in these pagan meetings.


In retros, the backlog grooming was something they listed under "things we
did well". In fact, the first backlog grooming meetings came out of a
Retro, as the team felt that the planning meeting kept going way too long
but we still weren't getting enough design done. I suggested a grooming
meeting and they loved it. So this was not management imposing a process.
It was a team self-improving. And I wouldn't think of excluding anyone
from the grooming. That would be counter productive.


I completely agree that PBI refinement is a continual process. But no one
that is suggesting a grooming meeting is saying that we whip people that
try to talk about stories outside of the meeting. We are just suggesting
that offering a safe and sanctioned time within the rhythm of the sprint to
allow the team so creative breathing room can be beneficial. And before Ron
latches on to the word "safe", I don't mean safe from me or from
management. I mean safe from the team's own internal expectations of
productivity. Self assigning a time in the sprint for grooming enhances
the work-think rhythm that already exists in Scrum. Part of the power of
Scrum is the focus in the sprint that you get from planning things out and
then plowing through them. Some teams will latch on to that rhythm and go
so heads down during the sprint that they will do minimal refinement
because they are so sprint goal focused. The grooming injects intentional
forward thinking into the sprint sage from that razor focus.


But that's just my experience.


-Cass

Post by Ron Jeffries ***@acm.org [SCRUMDEVELOPMENT]
H Wouter,
I see backlog refinement as a continuous process. I do have a full-team
session as part of that process (usually), but also many three-amigo's
sessions, or just impromptu discussions. To me, the proposal makes as much
sense as suggesting placing the development and test work for the sprint
into meetings.
The whole notion of backlog refinement is that it requires multiple skills
to refine a backlog item. The three amigos notion you raise reflects this,
suggesting that a business-focused person, a developer, and a tester should
come together to flesh out a story. In general, there are a few different
skills and understandings needed to really do a good job refining a story,
and unless the team members are quite broad in skills, different people
will be the right ones to contribute to different items.
We do not want everyone tied up: there is no need, and it’s wasteful. We
do not want the same people tied up all the time: diversity is good and we
benefit from cross-fertilization of ideas.
Finally, each item’s elaboration needs to happen at a different time and
different pace. Just as we don’t work on developing all items at once, but
have the whole team or the right subset work on one at a time, elaborating
the items wants to happen more or less one at a time, or in small related
batches, when the Product Owner is ready to work on them.
Rather than an all-hands meeting, or, worse, a meeting from which people
are excluded, what seems to work best is for the Product Owner to pop in,
account that she has a few stories about topic X to work on, and gather up
a few people who are interested, over the course of the Sprint.
Just as it takes a whole Sprint to develop the Sprint backlog items, it
takes a whole Sprint to refine the next ones: it just doesn’t require such
a large team.
That’s why Backlog Refinement is not a meeting, and why making it one
reduces effectiveness rather than increasing it. It’s an apparent
efficiency that loses effectiveness.
Ron Jeffries
ronjeffries.com
Impossible is not a fact. It is an opinion. -- Muhammad Ali

[Jesse Houwing [e-mail] [SCRUMDEVELOPMENT]]

I dislike the idea of an event, as it would require everyone in the room at

one point in time and would limit what you can do.


Some activities are part of refinement and go into the 10% allocation such
as mini spikes, creating a story board, sketching, a bit of impact analysis
and this can be done by only part of the team.


Sometimes you need stakeholders present to extract their needs, it makes
sense in many situations to visit them at their work place to gather what
is needed. Some stakeholders are notoriously hard to get hold of...


Many teams I work with do a three amigo type refinement where the team is
partially there.


Not all refinement goes towards the next sprint... Some may go into
understanding more long term planning or feasibility...


All in all, fixing the time and location and the whole team and forcing all
refinement to happen there and then, especially between two days that are
already filled up with meetings, just feels like completely wrong to me.


As to the context switching, that's just a matter of doing a bit of
refinement every day or every other day, and when you're talking to your

end users or stakeholder you might as well make use of their availability
to have them review the latest development and gather feedback. I'd want my

teams to regularly go out and interact with the PO, stakeholders and
end-users, focusing on both the current sprint and the upcoming wishes.


Jesse

Post by ***@yahoo.com [SCRUMDEVELOPMENT]
I just voted for the idea 'Include Backlog Refinement in the Scrum Events
section' in Scrumguide.uservoice.com, proposed by Jose Luis Soria (
http://scrumguide.uservoice.com/users/47440411-jose-luis-soria)
http://t.co/9HeoLDjyel
"I agree with this idea.
Though planning is an ongoing activity & yet we have events like time-boxed Scrum Planning.
Similarly backlog refinement is ongoing as an individual activity of the
PO but still we need to have it additionally as an event with the entire
team participation.
In fact I will go beyond this and suggest that this be scheduled as a
time-boxed event (10 % of the Sprint duration) immediately after sprint
retrospective and just before the next Sprint planning session of the next
sprint. Scheduling backlog refinement meeting as an event during a sprint
will shift the team member focus from the current sprint to the forthcoming
sprint. This will be a case of context switching which has been regarded as
a waste from Lean perspective.
But if a time-boxed backlog grooming is scheduled between two sprints the
team can give full focus. So a typical 2-week sprint schedule will look
like
Monday -First Half : Sprint Planning and
then after two weeks
Friday - First Half: Sprint Review and Sprint Retrospective
Friday - Second Half - Backlog refinement
Monday - First Half - Sprint Planning (next sprint)
One limitation with this approach is if the PO is not available on the
Backlog Refinement Event is scheduled then it will get adversely impacted.
But the same can be said of scheduled Sprint Planning session too."
Welcome your opinions.
- Gopinath

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

I see the backlog grooming as similar to the planning meeting. In fact, it

was the long planning meetings that lead us to the mid-sprint grooming.
The planning meeting is a whole-team event at a structured time and is part
of the rhythm of the sprint. I'm not sure how the mid-sprint grooming is
that different. The planning meeting requires everyone in the room at one
point. Every team's rhythm is different. I'm sure some teams would work
better by injecting the discussions we had in the grooming sessions
throughout the sprint. That doesn't make an explicit grooming meeting
wrong, and there are several explicit events in Scrum.


And I don't think anyone said anything about "forcing all refinement to
happen there and then". In fact, in my previous post, I noted that no one
kept refinement from happening outside of the meeting. It's that last
point that I think some people are missing. The existence of a refinement
meeting does not imply a lack of refinement outside of the meeting, just
like the existence of a planning meeting to start the sprint doesn't mean
that you are kept from doing any planning outside of that meeting. All I'm
saying is that some teams like to set aside some time to think about the
future. Thinking about the future is hard when you're heads down trying to
implement the current sprint. The only time that leaves is the planning
meeting, and if you're doing deep refinement in your planning meeting, the
time pressure of trying to get everything planned so that you can go and
start the sprint will compromise the creativity you need to do that deep
refinement.


The only guideline we had in our planning meeting was to have at least one
sprints worth of stories completely defined before we left. Everything
else was completely free form. Sometimes we would talk about stories that
were in next sprint, sometimes we would talk about an epic that was a
couple of months out. Everything was fair game to discuss. That is in
contrast to the planning meeting that is really about the sprint you're
about to start. Almost by definition, you are focused on only that
sprint. And during the sprint, the team can easily get so focused
executing the current sprint, time slips away from them and they can easily
forget to think about the long term.


And yes, stakeholders are notoriously hard to get a hold of. Which makes
gaining impromptu access to them almost impossible. I've found that you
actually have a BETTER chance of scheduling their time if there is a
dedicated time for discussing the long term.


Personally, I dislike the Three Amigo's form of refinement. Even if a
developer doesn't work on a story that is refined, it is the context about
the problem that they absorb and helps give them the bigger picture. I
have taken flack from program managers for having expensive meetings
because I bring the developers in from the start to have the conversations
with the customers. But even if they don't say a word at those meetings,
the amount of the big picture they are able to absorb is priceless. Any
story refinement that is required usually has a lot of good context and big
picture talk. Not having the team there to hear and/or contribute to that
discussion feels anti-agile to me.


-Cass

Post by Jesse Houwing ***@gmail.com [SCRUMDEVELOPMENT]
I dislike the idea of an event, as it would require everyone in the room
at one point in time and would limit what you can do.
Some activities are part of refinement and go into the 10% allocation such
as mini spikes, creating a story board, sketching, a bit of impact analysis
and this can be done by only part of the team.
Sometimes you need stakeholders present to extract their needs, it makes
sense in many situations to visit them at their work place to gather what
is needed. Some stakeholders are notoriously hard to get hold of...
Many teams I work with do a three amigo type refinement where the team is
partially there.
Not all refinement goes towards the next sprint... Some may go into
understanding more long term planning or feasibility...
All in all, fixing the time and location and the whole team and forcing
all refinement to happen there and then, especially between two days that
are already filled up with meetings, just feels like completely wrong to
me.
As to the context switching, that's just a matter of doing a bit of
refinement every day or every other day, and when you're talking to your
end users or stakeholder you might as well make use of their availability
to have them review the latest development and gather feedback. I'd want my
teams to regularly go out and interact with the PO, stakeholders and
end-users, focusing on both the current sprint and the upcoming wishes.
Jesse

Post by ***@yahoo.com [SCRUMDEVELOPMENT]
I just voted for the idea 'Include Backlog Refinement in the Scrum
Events section' in Scrumguide.uservoice.com, proposed by Jose Luis Soria
(http://scrumguide.uservoice.com/users/47440411-jose-luis-soria)
http://t.co/9HeoLDjyel
"I agree with this idea.
Though planning is an ongoing activity & yet we have events like
time-boxed Scrum Planning.
Similarly backlog refinement is ongoing as an individual activity of the
PO but still we need to have it additionally as an event with the entire
team participation.
In fact I will go beyond this and suggest that this be scheduled as a
time-boxed event (10 % of the Sprint duration) immediately after sprint
retrospective and just before the next Sprint planning session of the next
sprint. Scheduling backlog refinement meeting as an event during a sprint
will shift the team member focus from the current sprint to the forthcoming
sprint. This will be a case of context switching which has been regarded as
a waste from Lean perspective.
But if a time-boxed backlog grooming is scheduled between two sprints the
team can give full focus. So a typical 2-week sprint schedule will look
like
Monday -First Half : Sprint Planning and
then after two weeks
Friday - First Half: Sprint Review and Sprint Retrospective
Friday - Second Half - Backlog refinement
Monday - First Half - Sprint Planning (next sprint)
One limitation with this approach is if the PO is not available on the
Backlog Refinement Event is scheduled then it will get adversely impacted.
But the same can be said of scheduled Sprint Planning session too."
Welcome your opinions.
- Gopinath

[Jesse Houwing [e-mail] [SCRUMDEVELOPMENT]]

The spring not review meeting is already meant to to the long term view
with everyone in the room. Look at the feedback, and adjust the product
backlog is what the sprint review is all about.


I've worked with teams that have a dedicated slot, I've worked with teams
that have none. Both work pretty well. As I see it there is no need to
define an event for refinement. It may be a pattern that works well for
teams having trouble to organize refinement effectively without it, but
it's no one size fits all Solution.


Just like the removal of the 2-part sprint planning meeting in favor of one
that is free form, I'd prefer there to be no event for refinement, as it's
not required to make scrum work.


If you are struggling with continuous refinement, then a step up might be
to try out a meeting at a fixed slot. And extend the framework a little bit
for your environment.


It's not a one size fits all Solution.


As such it is no event. It's how we teach it in the course as well. Adjust
the way you do refinement to the environment you're in and make use of the
sprint review meeting as it is intended. To both inspect the increment and
to look ahead to adjust the backlog.


Jessr

Post by Cass Dalton ***@gmail.com [SCRUMDEVELOPMENT]
I see the backlog grooming as similar to the planning meeting. In fact,
it was the long planning meetings that lead us to the mid-sprint grooming.
The planning meeting is a whole-team event at a structured time and is part
of the rhythm of the sprint. I'm not sure how the mid-sprint grooming is
that different. The planning meeting requires everyone in the room at one
point. Every team's rhythm is different. I'm sure some teams would work
better by injecting the discussions we had in the grooming sessions
throughout the sprint. That doesn't make an explicit grooming meeting
wrong, and there are several explicit events in Scrum.
And I don't think anyone said anything about "forcing all refinement to
happen there and then". In fact, in my previous post, I noted that no one
kept refinement from happening outside of the meeting. It's that last
point that I think some people are missing. The existence of a refinement
meeting does not imply a lack of refinement outside of the meeting, just
like the existence of a planning meeting to start the sprint doesn't mean
that you are kept from doing any planning outside of that meeting. All I'm
saying is that some teams like to set aside some time to think about the
future. Thinking about the future is hard when you're heads down trying to
implement the current sprint. The only time that leaves is the planning
meeting, and if you're doing deep refinement in your planning meeting, the
time pressure of trying to get everything planned so that you can go and
start the sprint will compromise the creativity you need to do that deep
refinement.
The only guideline we had in our planning meeting was to have at least one
sprints worth of stories completely defined before we left. Everything
else was completely free form. Sometimes we would talk about stories that
were in next sprint, sometimes we would talk about an epic that was a
couple of months out. Everything was fair game to discuss. That is in
contrast to the planning meeting that is really about the sprint you're
about to start. Almost by definition, you are focused on only that
sprint. And during the sprint, the team can easily get so focused
executing the current sprint, time slips away from them and they can easily
forget to think about the long term.
And yes, stakeholders are notoriously hard to get a hold of. Which makes
gaining impromptu access to them almost impossible. I've found that you
actually have a BETTER chance of scheduling their time if there is a
dedicated time for discussing the long term.
Personally, I dislike the Three Amigo's form of refinement. Even if a
developer doesn't work on a story that is refined, it is the context about
the problem that they absorb and helps give them the bigger picture. I
have taken flack from program managers for having expensive meetings
because I bring the developers in from the start to have the conversations
with the customers. But even if they don't say a word at those meetings,
the amount of the big picture they are able to absorb is priceless. Any
story refinement that is required usually has a lot of good context and big
picture talk. Not having the team there to hear and/or contribute to that
discussion feels anti-agile to me.
-Cass

Post by Jesse Houwing ***@gmail.com [SCRUMDEVELOPMENT]
I dislike the idea of an event, as it would require everyone in the room
at one point in time and would limit what you can do.
Some activities are part of refinement and go into the 10% allocation
such as mini spikes, creating a story board, sketching, a bit of impact
analysis and this can be done by only part of the team.
Sometimes you need stakeholders present to extract their needs, it makes
sense in many situations to visit them at their work place to gather what
is needed. Some stakeholders are notoriously hard to get hold of...
Many teams I work with do a three amigo type refinement where the team is
partially there.
Not all refinement goes towards the next sprint... Some may go into
understanding more long term planning or feasibility...
All in all, fixing the time and location and the whole team and forcing
all refinement to happen there and then, especially between two days that
are already filled up with meetings, just feels like completely wrong to
me.
As to the context switching, that's just a matter of doing a bit of
refinement every day or every other day, and when you're talking to your
end users or stakeholder you might as well make use of their availability
to have them review the latest development and gather feedback. I'd want my
teams to regularly go out and interact with the PO, stakeholders and
end-users, focusing on both the current sprint and the upcoming wishes.
Jesse

Post by ***@yahoo.com [SCRUMDEVELOPMENT]
I just voted for the idea 'Include Backlog Refinement in the Scrum
Events section' in Scrumguide.uservoice.com, proposed by Jose Luis
Soria (http://scrumguide.uservoice.com/users/47440411-jose-luis-soria)
http://t.co/9HeoLDjyel
"I agree with this idea.
Though planning is an ongoing activity & yet we have events like
time-boxed Scrum Planning.
Similarly backlog refinement is ongoing as an individual activity of the
PO but still we need to have it additionally as an event with the entire
team participation.
In fact I will go beyond this and suggest that this be scheduled as a
time-boxed event (10 % of the Sprint duration) immediately after sprint
retrospective and just before the next Sprint planning session of the next
sprint. Scheduling backlog refinement meeting as an event during a sprint
will shift the team member focus from the current sprint to the forthcoming
sprint. This will be a case of context switching which has been regarded as
a waste from Lean perspective.
But if a time-boxed backlog grooming is scheduled between two sprints
the team can give full focus. So a typical 2-week sprint schedule will look
like
Monday -First Half : Sprint Planning and
then after two weeks
Friday - First Half: Sprint Review and Sprint Retrospective
Friday - Second Half - Backlog refinement
Monday - First Half - Sprint Planning (next sprint)
One limitation with this approach is if the PO is not available on the
Backlog Refinement Event is scheduled then it will get adversely impacted.
But the same can be said of scheduled Sprint Planning session too."
Welcome your opinions.
- Gopinath

[Cass Dalton [e-mail] [SCRUMDEVELOPMENT]]

I think I agree with that. +1 for scheduled grooming as a technique, -1
for adding it to the official scrum set of "must haves"

Post by Jesse Houwing ***@gmail.com [SCRUMDEVELOPMENT]
The spring not review meeting is already meant to to the long term view
with everyone in the room. Look at the feedback, and adjust the product
backlog is what the sprint review is all about.
I've worked with teams that have a dedicated slot, I've worked with teams
that have none. Both work pretty well. As I see it there is no need to
define an event for refinement. It may be a pattern that works well for
teams having trouble to organize refinement effectively without it, but
it's no one size fits all Solution.
Just like the removal of the 2-part sprint planning meeting in favor of
one that is free form, I'd prefer there to be no event for refinement, as
it's not required to make scrum work.
If you are struggling with continuous refinement, then a step up might be
to try out a meeting at a fixed slot. And extend the framework a little bit
for your environment.
It's not a one size fits all Solution.
As such it is no event. It's how we teach it in the course as well. Adjust
the way you do refinement to the environment you're in and make use of the
sprint review meeting as it is intended. To both inspect the increment and
to look ahead to adjust the backlog.
Jessr

Post by Cass Dalton ***@gmail.com [SCRUMDEVELOPMENT]
I see the backlog grooming as similar to the planning meeting. In fact,
it was the long planning meetings that lead us to the mid-sprint grooming.
The planning meeting is a whole-team event at a structured time and is part
of the rhythm of the sprint. I'm not sure how the mid-sprint grooming is
that different. The planning meeting requires everyone in the room at one
point. Every team's rhythm is different. I'm sure some teams would work
better by injecting the discussions we had in the grooming sessions
throughout the sprint. That doesn't make an explicit grooming meeting
wrong, and there are several explicit events in Scrum.
And I don't think anyone said anything about "forcing all refinement to
happen there and then". In fact, in my previous post, I noted that no one
kept refinement from happening outside of the meeting. It's that last
point that I think some people are missing. The existence of a refinement
meeting does not imply a lack of refinement outside of the meeting, just
like the existence of a planning meeting to start the sprint doesn't mean
that you are kept from doing any planning outside of that meeting. All I'm
saying is that some teams like to set aside some time to think about the
future. Thinking about the future is hard when you're heads down trying to
implement the current sprint. The only time that leaves is the planning
meeting, and if you're doing deep refinement in your planning meeting, the
time pressure of trying to get everything planned so that you can go and
start the sprint will compromise the creativity you need to do that deep
refinement.
The only guideline we had in our planning meeting was to have at least
one sprints worth of stories completely defined before we left. Everything
else was completely free form. Sometimes we would talk about stories that
were in next sprint, sometimes we would talk about an epic that was a
couple of months out. Everything was fair game to discuss. That is in
contrast to the planning meeting that is really about the sprint you're
about to start. Almost by definition, you are focused on only that
sprint. And during the sprint, the team can easily get so focused
executing the current sprint, time slips away from them and they can easily
forget to think about the long term.
And yes, stakeholders are notoriously hard to get a hold of. Which makes
gaining impromptu access to them almost impossible. I've found that you
actually have a BETTER chance of scheduling their time if there is a
dedicated time for discussing the long term.
Personally, I dislike the Three Amigo's form of refinement. Even if a
developer doesn't work on a story that is refined, it is the context about
the problem that they absorb and helps give them the bigger picture. I
have taken flack from program managers for having expensive meetings
because I bring the developers in from the start to have the conversations
with the customers. But even if they don't say a word at those meetings,
the amount of the big picture they are able to absorb is priceless. Any
story refinement that is required usually has a lot of good context and big
picture talk. Not having the team there to hear and/or contribute to that
discussion feels anti-agile to me.
-Cass

Post by Jesse Houwing ***@gmail.com [SCRUMDEVELOPMENT]
I dislike the idea of an event, as it would require everyone in the room
at one point in time and would limit what you can do.
Some activities are part of refinement and go into the 10% allocation
such as mini spikes, creating a story board, sketching, a bit of impact
analysis and this can be done by only part of the team.
Sometimes you need stakeholders present to extract their needs, it makes
sense in many situations to visit them at their work place to gather what
is needed. Some stakeholders are notoriously hard to get hold of...
Many teams I work with do a three amigo type refinement where the team
is partially there.
Not all refinement goes towards the next sprint... Some may go into
understanding more long term planning or feasibility...
All in all, fixing the time and location and the whole team and forcing
all refinement to happen there and then, especially between two days that
are already filled up with meetings, just feels like completely wrong to
me.
As to the context switching, that's just a matter of doing a bit of
refinement every day or every other day, and when you're talking to your
end users or stakeholder you might as well make use of their availability
to have them review the latest development and gather feedback. I'd want my
teams to regularly go out and interact with the PO, stakeholders and
end-users, focusing on both the current sprint and the upcoming wishes.
Jesse

Post by ***@yahoo.com [SCRUMDEVELOPMENT]
I just voted for the idea 'Include Backlog Refinement in the Scrum
Events section' in Scrumguide.uservoice.com, proposed by Jose Luis
Soria (http://scrumguide.uservoice.com/users/47440411-jose-luis-soria)
http://t.co/9HeoLDjyel
"I agree with this idea.
Though planning is an ongoing activity & yet we have events like
time-boxed Scrum Planning.
Similarly backlog refinement is ongoing as an individual activity of
the PO but still we need to have it additionally as an event with the
entire team participation.
In fact I will go beyond this and suggest that this be scheduled as a
time-boxed event (10 % of the Sprint duration) immediately after sprint
retrospective and just before the next Sprint planning session of the next
sprint. Scheduling backlog refinement meeting as an event during a sprint
will shift the team member focus from the current sprint to the forthcoming
sprint. This will be a case of context switching which has been regarded as
a waste from Lean perspective.
But if a time-boxed backlog grooming is scheduled between two sprints
the team can give full focus. So a typical 2-week sprint schedule will look
like
Monday -First Half : Sprint Planning and
then after two weeks
Friday - First Half: Sprint Review and Sprint Retrospective
Friday - Second Half - Backlog refinement
Monday - First Half - Sprint Planning (next sprint)
One limitation with this approach is if the PO is not available on the
Backlog Refinement Event is scheduled then it will get adversely impacted.
But the same can be said of scheduled Sprint Planning session too."
Welcome your opinions.
- Gopinath